Является ли структура приложения анти-паттерном?

Question

Недавно я реализовал пару веб-приложений аналогичного размера, в одном из которых использовалась «платформа», а в другом я сам кодировал, но использовал набор существующих (в основном, с открытым исходным кодом) библиотек, чтобы обеспечить определенные общие функции,В противном случае я бы использовал фреймворк для.

Я заметил следующее:

• Приложение на основе фреймворка было определенно быстрее настроено - оно эффективно работало"из коробки".Однако со временем и с добавлением дополнительных функциональных возможностей его обслуживание становилось все более сложным.Как только мне понадобилось что-то, что «не подходило» к фреймворку, я был вынужден прибегнуть к некоторым уродливым обходным путям.
• Приложение на основе библиотеки требовало больше кода при запускепривнести и интегрировать необходимые библиотеки, то есть вначале необходимо было написать разумное количество связующего кода.Но оказалось, что его легче расширять и пересматривать с течением времени, потому что не было никаких ограничений, связанных с необходимостью вписываться в дизайн структуры.

Из этого личного опыта у меня сложилось впечатлениеиспользование каркаса может считаться антишаблоном для долгосрочного сопровождения приложения.

Это действительно так?

Answer 1

Я думаю, что это очень субъективно.По моему мнению, прикладные инфраструктуры действительно являются антишаблоном, особенно для более крупных и сложных проектов.Я думаю, что для этого есть две причины.

Самая большая проблема, которую я вижу с фреймворками, заключается в том, что, используя фреймворк, вы отказываетесь от контроля.Дж. Б. Низет пишет: «Никто не заставляет вас использовать фреймворк для каждой части приложения», и это здорово, когда это так, но, к сожалению, обычно это не так.Обычно у фреймворка есть контроль, у вас есть обратные вызовы или производные классы, и когда вы хотите сделать что-то экстраординарное, вы не можете.,Чем хуже фреймворк, тем больше он ограничивает и тем больше он встает на пути пользователя фреймворка.Многие фреймворки, которые я видел, имеют некоторые фундаментальные ограничения, которые в конечном итоге ограничивают конечное приложение тем или иным способом.Я бы не сказал, что виноваты только создатели фреймворка, просто очень трудная, если не невозможная, попытка создать фреймворк, который не ограничивает пользователей фреймворка.

Фреймворки - это еще не всехотя плохоЕсли ваш проект хорошо вписывается в фреймворк и не выходит за его пределы, фреймворк ускоряет разработку.Небольшие структуры в приложении также имеют тенденцию упрощать вещи, когда они заботятся только об одной проблемной области, обычно без риска получить слишком много в пути.Но в конце фреймворки, с одной стороны, добавляют сложность, которая вам, вероятно, не понадобится, а с другой стороны, связывают интерфейс с движком, ограничивая пользователей фреймворка.

Answer 2

Нет, дело не в этом. Есть хорошие и плохие фреймворки, и есть фреймворки, подходящие для разрабатываемого вами приложения, и фреймворки, не подходящие для этого приложения. Вам просто нужно выбрать лучший инструмент для работы. Не предвидеть сложность приложения не обязательно является ошибкой фреймворка. Это может быть вашим, потому что вы просто не выбрали подходящую структуру для задачи.

Какой бы ни была выбранная среда, никто не заставляет вас использовать ее для каждой части приложения. Если фреймворк облегчает разработку 90% приложения и делает его слишком сложным для оставшихся 10%, просто не используйте фреймворк для этих 10%.

Answer 3

Я не думаю, что терминология шаблонов / анти-шаблонов очень полезна - она ​​говорит примерно столько же, сколько прилагательные «хорошо» и «плохо». Но я думаю, что у большинства фреймворков есть серьезные недостатки.

Сначала давайте определим, что такое фреймворк:

• Фреймворк предоставляет обратные вызовы или аналогичный механизм, который вы можете подключить к своему собственному коду. Большая часть вашего собственного кода выполняется внутри этих обратных вызовов.

Если фреймворк был человеком, то его девизом может быть «Не звони нам, мы позвоним тебе».

По определению вы вынуждены писать свой код в стиле, который соответствует структуре, а не в стиле, который соответствует приложению. Если эти два стиля не совпадают, уже существует очевидная проблема.

Фреймворк может изначально разрабатываться с учетом конкретной проблемы, и многие фреймворки довольно успешно решают эту проблему. Однако, как только начальная проблема была решена, большинство фреймворков, как правило, продолжают расти, охватывая все больше и больше функциональных возможностей, которые лишь смутно связаны с исходной проблемой.

Нередко можно увидеть веб-фреймворк, который также может обеспечивать безопасность, изменять размеры ваших изображений, обеспечивать инверсию управления или взаимодействовать с вашей базой данных. Фреймворк потерял фокус и старается быть всем для всех. Теперь это не удобно и не эффективно, и, вероятно, из-за недостатка фокуса возникают ошибки и неполные данные.

И тогда вам лучше с библиотекой, которая делает одно и делает это хорошо.