Аннотация: Должен ли я выбирать ASP.Net MVC поверх веб-форм или

Я работаю с веб-сайтом более 7 лет, и я обновил его с html- > ASP- > ASP.Net и теперь стал новым ароматом самого ASP.Net. Я должен был начать с MVC в прошлом году, но из-за крайнего срока и сложности, связанной с MVC, я не мог. Теперь, опять же, новое обновление - я начал с шаблонов ASP.Net DD (Dynamic Data) (последний, который подделывает таблицы БД и дает список, детализирует, редактирует и удаляет мастер).

Как я копаюсь, я узнаю, что он основан на MVC, и поэтому я буду использовать MVC (через DD) для создания своих веб-приложений. Я просмотрел много статей и сравнительных видеороликов между MVC и Web-Forms. Есть много тем даже на SO, мои абстрактные ссылки находятся в нижнем справочном разделе. Действительно, MVC оказывается более "контролируемым" и "расширяемым" шаблоном веб-разработки, поскольку некоторые говорят, что веб-формы все еще находятся рядом с ним (например, для создания тяжелых приложений, управляемых данными и т.д., То есть Sharepoint)

Мои веб-решения для цепочек поставок (пользователь должен войти в процедуру), и поэтому я не нужны функции SEO или другие вещи, полезные для типичной сети. Чтобы упростить, я делаю некоторые инвентаризации обслуживание (просмотр, добавление/изменение, удаление и amp; link) и несколько сложных экраны, такие как родительско-дочерние решетки и некоторые табличные макеты. Цель остается держать вещи простыми, но привлекательными и @ ядро, которое мы имеем производительность и удобство использования (большинство работает с наименьшими щелчками)

Итак, вот несколько моих сомнений как новичок MVCian:

  • Веб-формы управляются событиями, когда MVC будет выполнять это посредством действий, определенных в контроллерах
  • Неважно, пользуюсь ли я L2S или EF, моя бизнес-логика идет в модели (также расширена частичными классами)
  • URL-Routing расширит мою силу за рамки традиционного метода Querystring
  • Я смогу сделать мои каскадные сложные табличные макеты и сетки с помощью нескольких видов (т.е. частичных представлений и пользовательских элементов управления).
  • Такие вещи, как общие, грандиозные и т.д., могут быть видны в представлениях (представления надежды могут совместно использовать/передавать данные)
  • Некоторые фанковые функции графического интерфейса, такие как Frozen Grid-header/footer, прокрутка строк, табуляция и т.д., не приведут меня к беспорядочному представлению (или, по крайней мере, это возможно в чистом/организованном режиме)
  • У меня не будет "Viewstate" - в этом случае, где хранить временные данные? как текущий pageindex, порядок сортировки и т.д.
  • Я боюсь, что MVC может привести к сложной системе lenghty, где поток длинный. Я заблужусь? Является ли он масштабируемым, если я хорошо организовываю?

Собственно, theres больше, но я надеюсь, основываясь на вышеуказанных Qs, вы, эксперты, можете выяснить, какие веб-приложения я работаю, и поэтому я просто хочу начать инвестировать в нечто лучшее. Невозможно изменить архитектуру/подход каждые 6 месяцев!

Помогает ли DD сделать MVC неявным? Тогда как он может использовать элементы управления веб-формой? Извините, если я запутался, в этом случае, пожалуйста, поправьте меня! (Большинство работает с наименьшими щелчками)

Наконец, Может ли это быть решением: http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx

Также см. раздел EDIT.

Ссылки: (надеюсь, что это помогает другим, таким как я)

S ome good refs о MVC через web-froms и сравнение -

http://forums.asp.net/t/1459417.aspx (преимущества MVC над хорошо разработанным веб-формами) http://www.matthidinger.com/archive/2010/02/17/why-i-love-asp.net-mvc.aspx

Пожар в дыре:-) http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx http://www.codethinked.com/post/2010/0 http://www.codethinked.com/post/2010/01/22/Controls-Do-Not-Make-You-More-Productive.aspx

Еще несколько мнений по этому поводу:

v.good article: http://msdn.microsoft.com/en-us/magazine/dd942833.aspx

Резюме выше: http://mvark.blogspot.com/2009/08/aspnet-mvc-vs-web-forms.html

http://www.asp.net/mvc/tutorials/asp-net-mvc-overview--cs http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx

От SO:

http://stackoverflow.com/info/30067/
http://stackoverflow.com/info/361620/asp-net-mvc-vs-webforms-for-first-page-load-speed-for-big-projects/
http://stackoverflow.com/info/712220/whats-your-choice-for-your-next-asp-net-project-webforms-or-mvc/
http://stackoverflow.com/info/661181/asp-net-mvc-vs-webforms/
http://stackoverflow.com/info/1035642/asp-net-mvc-vs-webforms-speed-and-architecture-comparison/
http://stackoverflow.com/info/837831/mvc-versus-webforms/

EDIT # 1:

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

alt textalt textalt text

Plz не путайте меня с новичком web-dvpr. Я опытный, мне просто нужно знать (например, когда я говорю "Я буду потерян" ), достижится ли богатый графический интерфейс, и как ваш опыт в таких вещах... надеюсь, что помогает: -)

ОТВЕТЫ

Ответ 1

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

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

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

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

Вопрос, который вы задали: "Я заблужусь?" действительно зависит от вас и приложения, которое вы разрабатываете, но только вы можете ответить на него. Вы должны быть готовы уделить время изучению и пониманию MVC... потому что вы исходите из фона WebForms, будут изменения, которые вам не знакомы.

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

Обновление. Мой собственный опыт работы с MVC был чрезвычайно положительным. Я знаю и понимаю WebForms только из-за использования его в течение последних нескольких лет, но недавно я начал проект в своей компании, и, поскольку мне дали свободу выбора технологий, которые я хотел использовать, я решил, что было бы интересно попробуйте модель MVC в веб-приложении (требуется веб-приложение). Моя команда и я имели опыт работы с MVC в настольных приложениях, но все мы были неопытны в отношении веб-разработки в целом (в целом).

Опыт ASP.NET MVC был чрезвычайно плавным, и это был легкий переход для моей команды. Я заказал несколько книг для команды, мы потратили немного времени на то, чтобы приблизиться к нашему пониманию, и тогда мы начали развиваться (требования уже были выполнены до этого шага - мы были на стадии реализации). Как я уже говорил, это заняло неделю, и мы уже совершили большие скачки вперед - производительность была и остается очень высокой. Я очень доволен моделью MVC.

Вы, похоже, обеспокоены тем, что модель MVC приведет к тому, что ваше приложение превратится в кучу каши или станет неудобным для обслуживания. В целом это далеко не так. Вся идея разделенных проблем делает MVC идеальным для масштабируемости приложения, а также для повышения его ремонтопригодности и тестируемости. С учетом сказанного, многое из того, насколько хорошо растет приложение, зависит от понимания вашей команды парадигмы MVC и их навыков в качестве разработчиков. MVC не для всех, и не для каждого проекта. Есть также много других факторов, которые следует учитывать в отношении масштабируемости, которая не имеет ничего общего с MVC (дизайн базы данных, например, имеет ОГРОМНОЕ воздействие - возможно, больше, чем любая парадигма развития, которую вы выбираете). Мне лично нравится ASP.NET MVC, и у меня был очень хороший опыт, но вы должны принять во внимание все аспекты вашего проекта (члены команды, выделенное время, бюджет и т.д.), Чтобы принять окончательное решение.

Ответ 2

Я использовал MVC с момента его первого выпуска. Моя основная причина желания использовать MVC была связана с тем, что время загрузки SEO/страницы является важным фактором в создаваемых веб-приложениях, и я устал от того, что другие разработчики злоупотребляют ViewState в наших приложениях, несмотря на мои частые объяснения относительно того, почему 80 тыс. ViewState на домашней странице неприемлема.

Я хотел использовать Маршрутизирующий движок для прекрасных URL-адресов RESTful, поскольку в тот момент, когда я использовал IIS7 для перезаписи url на производстве, но не имел его на моей машине dev. Использование маршрутизации означало, что мне не пришлось снова настраивать правила перезаписи при развертывании в IIS7, поскольку маршруты находятся в коде внутри приложения. Механизм маршрутизации теперь доступен в ASP.Net 4.0 Web Forms, поэтому вы можете легко переключаться с параметров QueryString.

Примечание. Вы спрашиваете, где можно хранить временные данные, такие как индекс страницы, порядок сортировки и т.д. Я обычно привязываю их к URL-адресу. Этот подход работает как с Web Forms, так и с MVC, например.

http://example.com/products/1/asc

http://example.com/products/2/desc

Когда я впервые использовал MVC, я сразу заметил, что управление и проверка состояния занимает больше времени, чтобы реализовать пользовательские формы со многими полями, флажками, выпадающими списками и т.д. Это увеличит ваше время разработки, поскольку вам нужно написать собственный код для сохранения состояния, и если вы хотите, чтобы проверка на стороне клиента JavaScript была необходима, вам нужно также перевернуть свой собственный, т.е. не требуется никаких необходимых валидаторов полей. ViewState не является злом, и легко свернуть ViewState в приложении Web Form. Разработчик, злоупотребляющий ViewState, является злым.

В целом многие функциональные требования, о которых вы говорите, например. фанковые функции графического интерфейса, переписывание URL-адресов, в отличие от параметров строки запроса, вычислений и т.д., могут быть достигнуты как с MVC, так и с Web-формами, и с точки зрения конечного пользователя веб-сайт будет выглядеть одинаково. Самое большое, что предлагает MVC, - это условное обозначение шаблона проектирования. Причина, по которой я заставил MVC в моей команде разработчиков, заключается в том, что я хотел, чтобы разработчики в команде придерживались одного и того же соглашения и, таким образом, позволяли нам легче находить код друг друга. То, что я также люблю в MVC, заключается в том, что сделать SoC (Разделение проблем) намного проще. Вы не упоминаете TDD (тестовое развитие) в своем сообщении, но сделать TDD проще для достижения - это то, что MVC также приносит в таблицу.

Ответ 3

В настоящее время я работаю над веб-приложением ASP.NET MVC и смотрю как на Java Spring, так и на Rails в свое время, и если вы готовы работать за пределами экосистемы Microsoft, я настоятельно рекомендую Rails как наиболее продуктивный из трех. Обман подскажет вам, что он на 10 раз быстрее, и из того, что я видел, похоже, это реальность, а не просто реклама.

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

И да, я понимаю, что у вас нет опыта вне экосистемы Microsoft, но рельсы очень просты в освоении по сравнению с ASP.NET MVC и Java Spring/JSF, и стоит того, что нужно изучить.

Дай мне голос, я тебя осмеливаюсь.