Каковы основные различия между популярными веб-фреймворками?

Question

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

Меня больше всего интересует непосредственный опыт людей с одной или несколькими структурами, а не исчерпывающее сравнение всего, что есть. Надеемся, что в SO-сообществе есть программисты, которые имеют хороший и плохой опыт работы с такими вещами, как Rails , ASP.NET , Django , TurboGears или JSF . Также было бы здорово услышать, если кто-то использует одну из менее популярных сред, таких как Seaside или Weblocks .

Язык программирования является очевидной разницей, но Java против Ruby Flarewar не принесет особого удовольствия, и большинство из этих фреймворков, по-видимому, требуют не менее значительных инвестиций в технологии, инструменты и сложность, чем их язык выбора; так что меня больше интересуют такие вещи, как:

• Скорость разработки и удобство
• Барьеры для входа - как с точки зрения обучения разработчиков, так и необходимой инфраструктуры
• Lock-in - сколько кода вы могли бы сохранить, если бы вам пришлось переключать фреймворки?
• Гибкость - фреймворк диктует вашу архитектуру или дизайн? (Хорошо это или плохо, вероятно, лучше оставить для отдельного обсуждения.)
• Производительность, масштабируемость и стабильность - очевидно, в зависимости от разработчиков!

Answer 1

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

Скорость разработки и удобство

Для TurboGears , Пилоны и Django скорость разработки примерно равна. Будучи современными фреймворками, легко начать работу с нового сайта и начать собирать вместе страницы. Python известен своей быстрой разработкой и отладкой, и я бы сказал, что любая среда Python имеет более короткое время разработки, чем любая другая установка, с которой я работал (включая PHP, Perl, Embedded Perl и C # / ASP.Net).

Барьеры для входа - обучение разработчиков и инфраструктура

Если вы знаете Python и хотите посмотреть 20-минутное видеоурок , вы можете создать довольно полный сайт вики-типа с нуля. Или вы можете пройти через учебник по социальным закладкам за 30 минут (включая установку). Это примеры TurboGears, но у двух других фреймворков также есть почти идентичные руководства.

Инфраструктура тестирования / разработки, которая поставляется из коробки с этими фреймворками, как правило, достаточна для завершения большинства сайтов. В любой момент вы можете поменять компоненты в соответствии с требованиями вашей производственной среды. Например, SQLite отлично подходит для настройки ваших моделей и загрузки тестовых данных, но вы, возможно, захотите установить MySQL (например), прежде чем начать работу или хранить большие объемы данных.

Во всех случаях требования очень низкие и полностью продиктованы вашими требованиями к масштабируемости, а не какими-либо особенностями платформы. Если вы знакомы с определенным языком шаблонов или ORM, он, вероятно, подключится прямо.

Блокировка в

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

Гибкость

Это все о MVC с этими тремя фреймворками. Как вы сказали, это совсем другое обсуждение!

Производительность, масштабируемость и стабильность

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

Answer 2

Джанго против Струца.

Скорость разработки и удобство.

Django - запускается и запускается за время, необходимое для построения модели (в Python), определяет отображения администратора (2-3 строки кода на класс модели) и создает шаблоны HTML для работы со стандартными представлениями master-detail.

Struts - необходимо определить базу данных в SQL, а затем определить отображения ORM в iBatis. Затем определите, протестируйте и создайте различные компоненты приложения, используя классы действий и страницы шаблонов JSP. О, и мне нужно определить EJB для перемещения данных из приложения в JSP. Все это нужно для компиляции, и мне нужно проработать множество деталей, чтобы получить что-то, что соответствует правилам компиляции.

Препятствия для поступления - как с точки зрения обучения разработчиков, так и необходимой инфраструктуры

Постоянный во всех рамках и языках. Это в значительной степени безразличный предмет. Ни один язык или структура не являются легкими для обучения. Все веб-платформы имеют одинаковые требования к инфраструктуре.

Блокировка - сколько кода вы могли бы сохранить, если бы вам пришлось переключать фреймворки?

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

Гибкость - платформа определяет вашу архитектуру или дизайн? (Будет ли это хорошо или плохо, вероятно, лучше оставить для отдельного обсуждения.)

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

Производительность, масштабируемость и стабильность - очевидно, в зависимости от разработчиков!

Производительность - это язык (не рамки). Это дизайн. В некоторой степени, это также реализация конфигурации.

Масштабируемость - это основа (не язык). Это дизайн и конфигурация.

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

Answer 3

Это невероятно субъективный вопрос ... и это тег, который вы должны добавить к своему вопросу. Как уже предлагалось в нескольких комментариях, вы уже указали довольно хорошее руководство; что ты на самом деле спрашиваешь? Существует миллиард мнений о подобных вещах, и определенно нет правильного ответа!

Лично я начал использовать .html, перешел на php, попробовал ruby ​​(ненавидел его), открыл Python / DJango ... и с тех пор был счастлив. Хотя это (возможно) очень уникальный путь, поэтому ваш пробег может варьироваться:)