Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.
И вот мы возвращаемся к Фреймворкам.
Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.
Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.
Larvel
Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
Раз нет ООП, то и нет всей теории и принципов связанных с ним.
А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.
Если взглянуть глубже, то открывается ещё больше ада:
ActiveRecord.
Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
Далеко за
примерами ходить не нужно, уже треш.
Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)
Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
Повеситься. Сложность приложения зашкалит.
Symfony
Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".
Проблема с внедрением аспектов сквозь весь фреймворк, никуда не пропадает. Но тут по другой причине. Сложность платформенных компонентов зашкаливает. Все пишется с завязкой на конкретную реализацию, но получают все по строчке из DIC.
Потому что это центральная концепция. Другой нет.
Но, по правде говоря, слепить что-то годное возможность есть.
Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
И тут вы окажетесь правы — незачем.
Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
Спрашивается — и зачем? Просто потратили кучу времени.
Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.
