Какая альтернатива MVC?

MVC существует уже давно. Это проверенный временем шаблон. Многие фреймворки используют шаблон MVC. Мартин Фаулер разделил MVC на: ведущего ведущего и Пассивный просмотр.

Лучше всего это сказал архитектор Кристофер Александр:

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

Я не уверен, зачем вам переходить с MVC. Есть ли проблема, с которой вы сталкиваетесь, которую MVC не может решить красноречиво? Чтобы дать вам лучший ответ, нам нужно больше узнать о вашей проблемной области.

На что следует обратить внимание при рассмотрении шаблонов / архитектуры: если вы что-то создаете с помощью Myspace, вам понадобится надежная архитектура (MVC). Если вы создаете простой грубый интерфейс через Интернет - подойдет почти все.

Для веб-форм .Net (я предполагаю, что веб-формы, поскольку вы не сказали «толстый» или «веб-клиент»), которые не являются MVC, поддерживать их было кошмаром. Приложения веб-форм, просуществовавшие более пары лет, имели тенденцию превращаться в большие комья грязи. Уже тогда разработчики обнаружили способы использования MVC с веб-формами.

Как ни странно, отсутствие архитектуры MVC в веб-формах ASP.NET было одной из главных жалоб, которые привели к разработке Платформа ASP.Net MVC.

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

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

Классические приложения CRUD, созданные с использованием таких инструментов, как VB6 и Delphi, имеют пользовательский интерфейс, постоянное хранилище и не используют MVC. Большинство из них использовали элементы управления с учетом данных, напрямую связанные с полями базы данных.

Пара ссылок, сравнивающих различные шаблоны MV *, которые могут быть полезны: Шаблоны WPF: MVC, MVP или MVVM или…? & MVC, MVP и MVVM

Посмотрите на презентатора представления модели MVP.

Пользовательский интерфейс - это представление, а приложение всегда будет иметь модель, а мост между ними - контроллер. В целом MVC нет ничего особенного, потому что так будет всегда.

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

Я разработал альтернативу ASP.NET MVC. Вы получаете такую ​​же слабую связь и разделение проблем, но разница в том, как вы строите свои проекты.

В моем блоге есть несколько видеороликов, исходный код фреймворка, образец проекта и несколько надстроек VS.NET (элемент New Project, New Builder и New View).

Builder для ASP.NET

Некоторые ключевые отличительные особенности: 1. Шаблоны - это просто HTML - код не смешивается с шаблонами 2. Таким образом, шаблоны можно многократно использовать во всех представлениях, и дизайнеры веб-сайтов могут создавать шаблоны в своем инструменте дизайна по своему выбору 3. Строго типизированный код (без ViewData и прочего), поэтому вы получаете intillisense, проверку времени компиляции, навигацию по F12 и т. д. 4. Вы строите страницы как композиции представлений, а не наизнанку. 5. View можно рассматривать как «настоящие» классы. 6. Все соблюдается, поэтому компиляция во время выполнения отсутствует.

А также немало других отличительных факторов.

В теории :

MVC - это проверенная технология и яда-яда-яда, и она идеально подходит для веб-сайтов.

Но в реальном случае:

Для серьезного проекта, использующего MVC, требуется фреймворк, поэтому вы следуете фреймворку со всеми его ограничениями и ограничениями. Итак, на данный момент конкретная реализация MVC - это правило, а не просто «руководство».

Также MVC терпит неудачу для веб-сайтов, когда он собирается подключиться к модели, отличной от простого POST / GET, он терпит неудачу с асинхронизмом xml и терпит неудачу с ajax. (*)

(*) существует какой-то патч, но дизайн должен быть ясным и функциональным, и если вам нужно «исправить его», то он не будет ни ясным, ни функциональным.

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

ps: Большинство «хорошо сделанных» проектов MVC - это трехуровневые проекты.

ps2: MVC, за исключением некоторого фреймворка, это просто термин, НЕ ЯВЛЯЕТСЯ СЕРЬЕЗНОЙ ТЕРМИНОЛОГИЕЙ и отражен в группе «интерпретация mvc».