Я думаю, это зависит от того, действительно ли фреймворк решает для вас «трудную проблему» и легко ее решает. Люди всегда находят это по какой-то причине ужасно спорным, но в большинстве каркасов, которые я рассмотрел, я в конечном итоге отказался от работы, потому что написать код, чтобы сделать именно то, что я хочу, проще.
Позже, когда у меня возникнет проблема в моем коде, я могу просто пойти туда, где проблема, и добавить строку кода, чтобы исправить ее, вместо того, чтобы пробираться по страницам документации, чтобы найти магический параметр конфигурации. Если у меня есть проблема с (вставьте любимый фреймворк), я, как правило, нахожусь в поисках целую вечность, когда основная проблема, которую должен решать фреймворк, никогда не была такой сложной, во-первых.
Мои любимые бесполезные фреймворки - это те, которые требуют большого количества конфигурации и неуклюжего стандартного кода для выполнения основных задач, таких как отправка нескольких байтов в сокет или вставка некоторых параметров в подготовленный оператор и запуск его в базу данных. Еще один из моих фаворитов - целый набор «технологий XML», особенно «подключаемых» или «настраиваемых». (Почему мне нужна «подключаемая структура парсера», а не только один парсер, который всегда работает ...?) Назовите меня Виктором Мелдрю, но удивительно, как люди могут превратить 10-минутную проблему с регулярными выражениями в двухдневную проблема "сделай сам, сделай это" с X-in-the-title-do-it.
Теперь, несмотря на это, есть люди, которые абсолютно процветают на Spring, Hibernate, JSF, MVCJammer, Joomajamaventilate, вещах с 'X' в них и т. Д. И т. Д. Так что для некоторых людей в некоторых ситуациях очевидно, что они чудо и Я просто пропускаю жизнь.
Возможно, это зависит от того, имеете ли вы или ваша организация в основном опыт "конфигурации" и "объединения вещей" или "программирования"? Я полагаю, у меня есть больше последних.