5

Вопрос по web-frameworks – MVC или управляемые событиями компонентно-ориентированные веб-фреймворки? [закрыто]

Этот вопрос намеревается быть технологически независимым. Какой тип веб-фреймворков вы предпочитаете и когда:Pure MVC or event-driven component-oriented?

Просто для того, чтобы подчеркнуть «независимость от технологий», здесь я назову несколько MVC против компонентных веб-фреймворков в разных технологиях / языках:

  • Struts vs. Java Server Faces / Tapestry
  • The new ASP.NET MVC vs. "classic" ASP.NET
  • Cake PHP vs. PRADO
  • Error: User Rate Limit Exceeded

    от Pablo Marambio
  • Error: User Rate Limit Exceeded

    от
6 ответов
  • 1

    Лично я бы сказал

    что MVC - это путь для веб-сайтов. У вас гораздо больше контроля над HTML и CSS, и в то же время шаблон контроллера очень хорошо работает с HTTP. Веб-программирование, управляемое событиями, отлично подходит для небольших сайтов или для людей, которые не знакомы с HTML и CSS и более низкоуровневыми концепциями.

  • 2

    Используемая технология

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

    Если бы я мог выбрать технологию, в Java я бы выбрал Wicket. Я использовал Spring MVC, и это хорошо, но у Wicket есть замечательные функции, которых нет у Spring MVC: управление состоянием на стороне сервера и инкапсуляция, богатая модель компонентов, нет ненужных файлов сопоставления XML - только чистый Java и HTML.

  • 2

    Прямо сейчас

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

  • 1

    Я в первую очередь разработчик ASP.Net

    но считаю, что MVC - лучший способ создания функционально сложных веб-сайтов (обычно сайтов бизнес-типа), поскольку он позволяет лучше отделить бизнес-логику и правила от разметки, используемой для отображения данные для конечного пользователя. Для быстрых и грязных сайтов (обычно с прямым подключением к базе данных) или более богатых интерфейсов, & quot;event-driven component-oriented& Quot; Модель более эффективна.

  • 0

    Я свободно следую этим рекомендациям:

    Web Forms/SQLDataSource- Quick and dirty app for internal use to show reporting or some other such data. MVC- Simple to complex business logic for a core product. MVC/REST Web Services/jQuery- HTML/Whatever type of client RIA's (when user experience reigns supreme). Flash/Flex RIA- Useful when an extremely rich client is needed (think multimedia manipulation here).

    Конечно, в этом списке много пробелов, но это просто показывает, насколько сложен вопрос.

  • 5

    Я - php dev по дням

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

    MVC, как воплощено всеми этими «MVC» фреймворки кажутся отстойными, вы получаете логическую страницу с кучей элементов управления, и вам приходится обрабатывать все эти элементы на контроллерах страниц, вау, спасибо, теперь у меня есть MVC / n, где n - количество элементов управления. Большинство 'MVC' системы, которые я видел до сих пор, представляли собой смесь библиотек с мертвыми мозгами, объединяющих ответ на запрос в единый контроллер, который должен знать обо всем на странице.

    Шаблоны xhtml с js и css прекрасно разделены. Наряду с несколькими классами, поддерживающими эти компоненты, и внезапно вы не задаетесь вопросом, как будут работать сложные страницы, или если вы хотите взять кусок x и выбросить его куда-нибудь еще.