Этот вопрос направлен на выявление преимуществ и недостатков использования веб-платформ : таких как Cake PHP, Zend, jQuery, ASP.NET). Этот вопрос совершенно не зависит от языка . Позвольте мне начать с понятия «Стоять на плечах гигантов ».

Преимущества:

• Позволяет разработчикам - взяв на себя функции, которые раньше занимали бы сотни строк кода, и сжимая их в один простой вызов функции, разработчики могут интегрировать более сложные функции в свои веб-сайты.
• Разрешить более быструю разработку приложений - это очень актуально для людей, которым нужны сайты, созданные в очень маленьком окне (есть ли у кого-нибудь примеры этого?)
• Низкие затраты - позволяет программистам перенести экономию средств на клиента - создан целый ряд новых клиентов, которым нужен веб-сайт, но ранее они не могли позволить себе более высокие затраты на разработку.

Недостатки:

• Потерянное понимание - полагаясь на особенности фреймворка, разработчик рискует потерять понимание того, как все работает (под капотом).
• Обрыв конфигурации - как только вы пойдете дальше, чем конфигурация вашей инфраструктуры, ваша производительность сразу упадет, может быть сложно реализовать функции вне конфигурации инфраструктуры.
• Трамвайная линия разработчика - вы (разработчик) должны делать то, что разработчик хочет, чтобы вы делали.

Интересно, что люди делают из моих очков, и не согласен ли кто-нибудь с ними? Также, если у людей есть дополнительные очки, я был бы благодарен.

Вот суть: может быть сложно реализовать функции вне конфигурации фреймворка.

Давайте рассмотрим это предположение по предположению.

Потерянное понимание - полагаясь на особенности фреймворка, разработчик рискует потерять понимание того, как все работает (под капотом).

Ложь. Вы никогда не потеряете понимание того, как все работает. Рамки не волшебные. Это просто удобный код, который вам не нужно писать самому.

Верьте или нет, вы будете делать ошибки, используя рамки. Вам придется отлаживать вплоть до самых низких уровней HTTP, чтобы понять, что вы сделали неправильно.

Вы никогда не упустите из виду то, что происходит под капотом. Если, конечно, ваша структура настолько эпична и совершенна, что у вас никогда не будет проблем.

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

Это имеет очень мало смысла.

Первый. Сборка без фреймворка может превратить тривиальную работу в большую задачу программирования, которая включает в себя модульное тестирование, отладку, диагностику, управление конфигурацией и все другие бесполезные работы по переосмыслению вещей, которые есть в фреймворке. Как это "производительность"?

Во-вторых. Реализация чего-либо вне фреймворка - это всегда много работы, потому что - хм, реализация чего-либо вне фреймворка - это всегда много работы. Это не имеет никакого отношения к времени, потраченному на изучение и настройку фреймворка. Реализация чего-либо вне рамок по своей сути сложна.

Трамвайная линия разработчика - вы (разработчик) должны делать то, что разработчик [фреймворка] хочет, чтобы вы делали.

Верный. И это часто хорошо. Делать вещи последовательным способом более ценно, чем делать их по своему усмотрению. Это может потребовать «обучения» и «понимания», но они имеют ценность.

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

Какая? Это не имеет ничего общего с рамками. Мошенничество - это мошенничество, независимо от используемых инструментов.

Con: возможное падение поддержки / потеря популярности

• Если есть две веб-фреймворки, которые в основном делают одно и то же, а ваша не выигрывает, есть шанс, что проект умрет. В этой ситуации вам остается самостоятельно поддерживать фреймворк (с открытым исходным кодом), переписать приложение или продолжить без обновлений (с закрытым исходным кодом).
• В зависимости от платформы, вы можете быть вынуждены обновить свое приложение с графиком выпуска платформы. Слишком большое отставание может лишить вас права на поддержку. Без рамок вы можете работать по расписанию. (Это зависит от того, нужна ли вам поддержка или нет).

Pro: код для бизнеса

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

преимущества

• Ускоренное время разработки
• Меньше ошибок
• Быстрая совместная разработка
• Поддержка библиотеки
• Простое взаимодействие с БД

Недостатки

• "В штучной упаковке" в рамки
• Часто негибки, когда хотят расширить или изменить поведение ядра
• «Ошибки обреченности» - ошибки, которые возникают в ядре или в базовой архитектуре и не имеют обратной связи с местом их возникновения. Прекрасным примером являются ошибки Spring при использовании Grails.

Я выступаю за использование фреймворков для всех проектов, кроме самых простых. Если вам нужно добавить форму обратной связи к существующему сайту HTML, вы можете использовать один файл PHP вместо перехода на платформу.

Несколько вещей, которые приходят на ум ...

преимущества

• Повторное использование кода - используя платформу, вы повторно используете проверенный и верный код.
• Быстрое развитие / прототипирование.
• (часто) встроенная проверка входных данных, которая может считаться безопасной (если разработчик использует ее правильно)

Недостатки

• Потеря поддержки. Здесь на ум приходит Symfony 1.4. Я предполагаю, что Symfony будет поддерживать 1.4 в течение некоторого времени, но, зная, что 2.0 не имеет обратной совместимости, 1.4 в ближайшие годы кажется тупиком поддержки.
• Накладные расходы; Используя платформу, вы запускаете тысячи строк, которые могут не относиться к вашему конкретному приложению, но могут применяться к другим. Некоторые считают это разумным компромиссом, а некоторые предпочитают писать свой код с нуля для повышения производительности.
• Использование неправильной структуры для ваших конкретных потребностей. Не все рамки созданы одинаково.

Все зависит от того, какую платформу вы используете.

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

ASP.NET MVC стремится решить эту проблему, и это хорошо.

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

Я хотел бы добавить несколько пунктов.

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

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

Преимущества:

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

Я говорю из личного опыта за последние 13 лет. В моей компании мы использовали распорки, после короткого поворота это было здорово. В моем следующем примере мы использовали архитектуру, которая была в основном непрозрачной, несколько похожей на структуру, но выросла, мы могли расширить ее, но основной код был только jars. И так далее. последние 3 года работали в небольшой компании (количество разработчиков <30) и это были все наши собственные jsps, servlets и ejbs. Если посмотреть на наших многочисленных клиентов и повторение jsps, в 2012 году был создан фильтр j2ee, который имитировал 20% стоек2. Почему бы не использовать Stuts 2? Хотелось бы, чтобы мы имели, но: не могли передать его нашему главному архитектору; недостаточно опыта или времени.

Итак, у нас были перехватчики некоторых распространенных jsps, которые использовала наша мини фреймворк. Теперь, когда у меня было время пройти через книгу о стойках 2, я вижу, что мы так много пропустили!

Мы используем некоторые отличные алгоритмы, кеши и пользовательский интерфейс, но потеряли много часов и обременены большим количеством кода, который мы планируем удалить на 3 года.