ASP.NET MVC подходит для сложных веб-приложений?

Question

На прошлой неделе мой босс попросил мою команду оценить ASP.NET MVC для следующего проекта. все мы работаем с webform начиная с .NET 1.1, у нас раньше не было опыта работы с MVC, но все мои коллеги интересуются ASP.NET MVC, но, к счастью, наш окончательный ответ - НЕТ.

Потому что:

1. Мы считаем, что, хотя вы и являетесь ASP.NET Guru, вы можете создать сложное приложение за короткое время. Но если вы переключитесь на ASP.NET MVC, время разработки займет больше времени, все, что нужно с помощью html helper, без веб-элемента управления и многими вопросами, продолжайте открывать вкладку Firefox с форумом ASP.NET, чтобы задать вопрос с практическими рекомендациями.

2. Мы видели, как много раз люди говорили, что MVC обеспечивает лучшее управление проектами, но если это сложный веб-сайт, я могу представить, что на одной странице есть сотни тегов <% =%>, и держать открытым контроллер, чтобы видеть что вернуть, и продолжать открывать модель, чтобы увидеть логику.

Я могу сказать, что MVC неплох, но Webform достаточно силен, чтобы справиться с этой задачей.

Answer 1

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

С MVC вы должны избавиться от старого мышления ASP.NET Forms «сложного веб-приложения» в том смысле, «сколько у нас страниц, более 300 страниц! Это было бы огромно!». Вы меняете вид всего вашего приложения. Вы переходите от старого мышления «какую страницу нужно создать дальше» к мышлению MVC о том, «какую функцию нам нужно реализовать дальше».

Например, я сам взял под свой контроль проект, который содержит более 3300 файлов только в «веб-проекте» (плюс 11 вспомогательных сборок). Одна вещь, которую я создаю, - это то, как MVC резко сократит количество физических файлов примерно до 310 или около того. Как? Потому что я ухожу от «вот одна страница. Вот другая страница». к «вот функции, которую я хочу реализовать» мышления.

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

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

Теперь, что касается «без веб-контроля», как вы упомянули: опять же, это требует другого способа мышления. Существует HtmlHelper, который используется для базового рендеринга и кодирования. Я использую ту же концепцию с абстрагированным классом MyProjectHelper, который отображает мои «функции» на странице (functions = code).

Например, я всегда создавал серверный элемент управления для моих DisplayNames в прошлом. Это позволило мне контролировать способ отображения DisplayName, особенно с переключением на Facebook Connect и другими вещами. В MVC я больше не использую «серверный элемент управления», а «функцию» в ViewModel для визуализации этого текста: CollegeProjectViewModel.RenderDisplayName (). Так как это только часть уровня пользовательского интерфейса, он будет отображать привязку по мере необходимости с любыми опциями, которые я захочу (конечно, аннотация наследуется CollegeProjectViewModel, который обрабатывает «базовый» рендеринг текста).

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

Answer 2

Я работал над проектом MVC в моей последней компании в течение 6 месяцев (мы использовали сборки CTP и в конечном итоге сборки бета-версии). Поначалу это было весело и увлекательно, и казалось, что мы действительно чего-то хотели. Как и многие разработчики .NET, мы устали от неплотных абстракций веб-форм.

Однако с течением времени мы начали сомневаться в нашем решении. Разработка пользовательского интерфейса занимала около 80% нашего времени. Мы должны были построить весь наш пользовательский интерфейс с нуля. Половину времени казалось, что мы заново изобретаем колесо. Большая часть нашего богатого пользовательского интерфейса исходила от JQuery в сочетании с пользовательскими помощниками HTML, которые было интересно разрабатывать, но занимало много времени.

Были и другие проблемы, с которыми мы сталкивались, например, необходимость DTO-подобных объектов отображать из наших бизнес-объектов (извлекаемых из репозитория, поддерживаемого NHibernate), в Views. И наши контроллеры, которые должны были быть легкими и простыми в обслуживании, становились все более беспорядочными, и мы постоянно спорили о том, как правильно реализовать наследование контроллеров.

Оглядываясь назад, я чувствую, что все проблемы, с которыми мы столкнулись, были связаны с отсутствием у нас опыта и понимания MVC. Нам всем понравилась идея MVC, но у нас просто не было практического опыта и ноу-хау, чтобы эффективно использовать ее в том, что я считаю очень сложным (представьте что-то в духе Sales Force, но с лучшей отчетностью) приложением .

- ОБНОВЛЕНИЕ -

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

- ОБНОВЛЕНИЕ 2011 -

После нескольких проектов MVC разных размеров за последний год или около того я стал своего рода новообращенным. Все реальные проблемы, которые у меня были с этим, были в основном решены в последних версиях (2 и 3), особенно те, которые касаются проверки модели и привязки к представлениям и из них.

Хотя одна вещь: создавать высокоинтерактивные сетки данных все еще может быть немного утомительно, что еще немного проще в WebForm. Тем не менее, есть сторонние предложения, которые предоставляют полезные расширения MVC, что делает это менее важным. Лично я использую предложения Telerik для больших целей.

Answer 3

Среди многих преимуществ использования MVC - удаление свиного состояния.

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

С другой стороны, обратите внимание на .NET v4.0, который позволит вам управлять состоянием представления на уровне управления, а не только на уровне страницы. Это сделает MVC еще менее привлекательным.

Answer 4

Я пришел с веб-разработки (как и вы), с 1.0 до 3.5. Когда я обнаружил MVC (CTP), мне потребовалось около 6 месяцев, чтобы убедить моих сверстников (и моего босса), что это путь.

Некоторые основные моменты моих аргументов:

1. Полный контроль над HTML
2. TRUE AJAX (вместо панели обновления)
3. Возможность использования jQuery в геометрической прогрессии
4. Нет VIEWSTATE
5. Отделение концерна
6. .. и .. (барабанная дробь) ... более быстрое развитие

Хотя # 6 немного субъективен, но я попытался доказать это путем создания прототипов. Для своего прототипа я создал простое веб-приложение для панели мониторинга, используя веб-форму и asp.net mvc. Я показал результат своим сверстникам и моему боссу, а также сложность построения и обслуживания каждого из них. В конце концов, мы перенесли нашу основную методологию с веб-формы на MVC.

Это правда, что требуется некоторое время, чтобы "разучить" некоторую парадигму веб-формы. Но как только вы получите его, MVC станет намного проще, и вы сможете работать с ним.

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

TRUE AJAX также довольно сложен в веб-форме. UpdatePanel играет свою роль, но у вложенных панелей обновлений есть и свои проблемы.

Для меня и моих коллег это сводится к возможности контролировать наш HTML / code / AJAX - вместо того, чтобы автоматически генерировать 90% фреймворком, но мы должны потратить много времени и усилий, чтобы получить остальные 10% .

ASP.NET MVC в сочетании с jQuery и предпочитаемой вами структурой уровня бизнес-пользователей или ORM чрезвычайно эффективны. На сегодняшний день мы выпустили 3 рабочих выпуска с ASP.NET MVC, и все они работают хорошо - черт возьми, посмотрите на stackoverflow.com (он использует MVC, кстати).

Answer 5

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

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