Кто-нибудь рядом со мной просто НЕ получает ASP.NET MVC?

Я играл с ASP.NET MVC с CTP, и мне нравится много всего, что они делали, но есть вещи, которые я просто не получаю.

Например, я скачал beta1, и я собираю с ним небольшой личный сайт / резюме / блог. Вот fragment из представления ViewSinglePost:

 
<% Response.Write(Html.ActionLink("< >", "view", new { id = ViewData.Model.NextPost.Id })); %>

Отвратительно! (Также обратите внимание, что в HTML есть временный HTML-код заполнителя, после создания функциональности я сделаю фактический проект) .

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

Все проповедуют, как вы можете сделать более чистый HTML. Угадай, что? 1% всех людей смотрят на выведенный HTML. Для меня, мне все равно, если Webforms испортит мой отступ в визуализированном HTML, если у меня есть код, который легко поддерживать … Это не так!

Итак, конвертируйте меня, мудрый парень из веб-форм, почему я должен отказаться от своих красиво оформленных страниц ASPX для этого?

Edit: Bolded «temp Html / css», чтобы люди могли это сделать.

По сравнению с веб-формами MVC одновременно является подходом более низкого уровня к генерации HTML с большим контролем над выходом страницы и более высокоуровневым, более архитектурным подходом. Позвольте мне захватить веб-формы и MVC и показать, почему я думаю, что сравнение благоприятствует веб-формам во многих ситуациях – до тех пор, пока вы не попадете в некоторые classические ловушки веб-форм.

Веб-формы

В модели Web Forms ваши страницы соответствуют запросу страницы в браузере. Таким образом, если вы направляете пользователя в список книг, у вас, вероятно, будет страница с названием «Booklist.aspx», на которую вы будете направить его. На этой странице вам нужно будет предоставить все необходимое для отображения этого списка. Это включает в себя код для вытягивания данных, применения любой бизнес-логики и отображения результатов. Если на странице есть какая-либо архитектурная или маршрутизирующая логика, вам также необходимо закодировать архитектурную логику на странице. Разработка хороших веб-форм обычно включает в себя разработку набора поддерживающих classов в отдельной (единичной тестируемой) DLL-библиотеке. Эти classы будут обрабатывать бизнес-логику, доступ к данным и решения архитектуры / маршрутизации.

MVC

MVC использует более «архитектурный» вид разработки веб-приложений: предлагая стандартизованные леса для построения. Он также предоставляет инструменты для автоматического создания classов моделей, представлений и controllerов в рамках установленной архитектуры. Например, в Ruby on Rails (только здесь «Rails») и ASP.NET MVC вы всегда начинаете с структуры каталогов, которая отражает их общую модель архитектуры веб-приложений. Чтобы добавить представление, модель и controller, вы будете использовать такую ​​команду, как Rails «Rails script / generate scaffold {modelname}» (ASP.NET MVC предлагает аналогичные команды в среде IDE). В результирующем classе controllerа будут найдены методы («Действия») для Index (show list), Show, New и Edit and Destroy (по крайней мере, в Rails, MVC аналогичен). По умолчанию эти действия «Get» просто связывают модель и маршрутизируются в соответствующий файл view / html в каталоге «View / {modelname}» (обратите внимание, что есть также действия Create, Update и Destroy, которые обрабатывают «Post», и вернитесь к индексу или показу).

Макет каталогов и файлов имеет большое значение в MVC. Например, в ASP.NET MVC метод Index для объекта «Book», скорее всего, имеет только одну строку: «Return View ();» Через магию MVC это отправит модель книги на страницу «/View/Books/Index.aspx», где вы найдете код для отображения книг. Подход Rails подобен, хотя логика немного более ясна и менее «волшебна». Страница просмотра в приложении MVC обычно проще, чем страница веб-форм, потому что им не нужно беспокоиться о маршрутизации, бизнес-логике или обработке данных.

сравнение

Преимущества MVC сводятся к чистому разделению проблем и более чистой, большей HTML / CSS / AJAX / Javascript-ориентированной модели для производства вашей продукции. Это улучшает тестируемость, обеспечивает более стандартизованный дизайн и открывает дверь на веб-сайт типа «Web 2.0».

Однако есть и некоторые существенные недостатки.

Во-первых, в то время как легко получить демонстрационный сайт, общая архитектурная модель имеет значительную кривую обучения. Когда они говорят «Конвенция над конфигурацией», это звучит хорошо – пока вы не поймете, что у вас есть соглашение об учете книги для изучения. Кроме того, часто бывает сложно разобраться в том, что происходит, потому что вы полагаетесь на магию, а не на явные вызовы. Например, «Return View ()»; позвонить выше? Тот же самый вызов можно найти в других действиях, но они идут в разные места. Если вы понимаете соглашение MVC, тогда вы знаете, почему это делается. Тем не менее, он, конечно, не квалифицируется как пример хорошего именования или легко понятного кода, и для новых разработчиков гораздо труднее подобрать Web-формы (это не просто мнение: в прошлом году у меня была летняя школа, изучающая Web Forms и MVC в этом году, а различия в производительности были выражены – в пользу веб-форм). BTW, Rails немного лучше в этом отношении, хотя Ruby on Rails имеет динамически называемые методы, которые также требуют серьезного использования.

Во-вторых, MVC подразумевает, что вы создаете classический веб-сайт в стиле CRUD. Архитектурные решения и особенно генераторы кода созданы для поддержки этого типа веб-приложений. Если вы создаете CRUD-приложение и хотите использовать проверенную архитектуру (или просто не нравится дизайн архитектуры), то вам, вероятно, следует рассмотреть MVC. Однако, если вы будете делать больше, чем CRUD, и / или вы достаточно компетентны в архитектуре, тогда MVC может чувствовать себя смирительной рубашкой, пока вы действительно не освоите базовую модель маршрутизации (что значительно сложнее, чем просто маршрутизация в приложении WebForms). Даже тогда я чувствовал, что я всегда сражаюсь с моделью и беспокоюсь о неожиданных результатах.

В-третьих, если вы не заботитесь о Linq (потому что вы боитесь, что Linq-to-SQL исчезнет или потому, что вы найдете Linq-to-Entities смехотворно перепроизводство и под управлением), то вы также не хотите пройти этот путь, поскольку инструменты ASP.NET MVC для строительных лесов строятся вокруг Linq (для меня это был убийца). Модель данных Rails также довольно неуклюжая по сравнению с тем, что вы можете достичь, если у вас есть опыт SQL (и особенно если вы хорошо разбираетесь в TSQL и хранимых процедурах!).

В-четвертых, сторонники MVC часто указывают, что взгляды MVC ближе по духу к HTML / CSS / AJAX-модели сети. Например, «Помощники HTML» – маленькие кодовые вызовы на вашей странице vew, которые меняются по содержимому и помещают их в элементы управления HTML, гораздо проще интегрировать с Javascript, чем элементы управления Web Forms. Тем не менее, ASP.NET 4.0 вводит возможность назвать ваши элементы управления и, таким образом, в значительной степени устраняет это преимущество.

В-пятых, пуристы MVC часто высмеивают Viewstate. В некоторых случаях они правы. Тем не менее, Viewstate также может стать отличным инструментом и благом для производительности. Для сравнения, обработка ViewState намного проще, чем попытка интегрировать сторонние веб-элементы управления в приложение MVC. Хотя интеграция управления может стать проще для MVC, все текущие усилия, которые я видел, страдают от необходимости создавать (несколько громоздкий) код для привязки этих элементов управления к classу Controller (то есть – для работы с моделью MVC ).

Выводы

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

Тем не менее, я предпочитаю разработку Web Forms, потому что для большинства задач просто проще сделать что-то (исключение – генерация набора CRUD-форм). MVC также, похоже, в некоторой степени страдает от избытка теории. В самом деле, посмотрите на многие вопросы, заданные здесь SO, людьми, которые знают ASP-ориентированный ASP.NET, но которые пытаются MVC. Без исключения, есть много скрежеток зубов, поскольку разработчики находят, что они не могут выполнять базовые задачи, не прыгая через обручи или не выдерживая огромную кривую обучения. Это то, что делает Web Forms выше MVC в моей книге: MVC заставляет вас платить реальную мировую цену , чтобы получить немного больше тестируемости или, что еще хуже, просто быть здоровым, потому что вы используете новейшие технологии.

Обновление: меня сильно критиковали в разделе комментариев – некоторые из них вполне справедливы. Таким образом, я провел несколько месяцев, изучая Rails и ASP.NET MVC, чтобы удостовериться, что я действительно не упустил следующую большую вещь! Разумеется, это также помогает обеспечить сбалансированный и адекватный ответ на этот вопрос. Вы должны знать, что вышеупомянутый ответ является основным переписанием моего первоначального ответа в случае, если комментарии выглядят не синхронизированными.

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

Что касается тех, кто видел это как религиозную битву и неустанно создавал streamи наводнений, я не понимаю, почему вы беспокоитесь (20+ голосов в несколько секунд друг от друга в несколько раз, конечно, не нормальные). Если вы читаете этот ответ и задаетесь вопросом, есть ли что-то действительно «неправильное» в моем ответе, учитывая, что оценка намного ниже, чем некоторые другие ответы, будьте уверены, что в нем говорится о нескольких людях, которые не согласны с общим чувством сообщество (в целом, это было поддержано более 100 раз).

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

MVC дает вам больше контроля над вашим продуктом, и с этим контролем возникает больший риск написания плохо разработанного HTML, суп-суп и т. Д.

Но в то же время у вас есть несколько новых вариантов, которых у вас не было раньше …

  1. Больше контроля над страницей и элементами на странице
  2. Меньше «мусора» в вашем выпуске, например ViewState или слишком длинных идентификаторов на элементах (не поймите меня неправильно, мне нравится ViewState)
  3. Лучшая возможность программирования на стороне клиента с помощью Javascript (приложения для Web 2.0?)
  4. Не просто MVC, но JsonResult – пятно …

Теперь это не означает, что вы не можете делать какие-либо из этих действий с помощью WebForms, но MVC упрощает работу.

Я все еще использую WebForms, когда мне нужно быстро создать веб-приложение, так как я могу использовать серверные элементы управления и т. Д. WebForms скрывает все детали входных тегов и кнопки отправки.

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

[Обновить]

Если это и есть любое утешение, MVC – это всего лишь новая, развивающаяся технология от Microsoft. Было много сообщений, которые WebForms не только останутся, но и будут развиваться для …

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

… и так далее…

Для тех, кто беспокоится о маршруте, который принимает MVC, я бы предложил дать «ребятам» ваши отзывы. Кажется, они слушают!

Большинство возражений против ASP.NET MVC, похоже, сосредоточены вокруг представлений, которые являются одним из самых «необязательных» и модульных битов в архитектуре. NVelocity , NHaml , Spark , XSLT и другие механизмы просмотра могут быть легко заменены (и с каждым выпуском стало легче). Многие из них имеют намного более сжатый синтаксис для выполнения логики представления и форматирования, сохраняя при этом полный контроль над выпущенным HTML.

Кроме того, почти каждая критика, похоже, доходит до отметки <%%> в представлениях по умолчанию и как «уродливая». Это мнение часто связано с использованием подхода WebForms, который просто переносит большую часть classического ASP-уродства в файл кода.

Даже не делая ошибок кода «неправильно», у вас есть такие вещи, как OnItemDataBound в репитерах, что так же эстетично уродливо, если только по-другому, чем «суп-тег». Цикл foreach может быть намного легче читать, даже с переменным вложением в выход этого цикла, особенно если вы попадете в MVC из других технологий nonASP.NET. Для понимания цикла foreach требуется гораздо меньше Google-fu, чем выяснять, что способ изменить это поле в вашем ретрансляторе – это связать с OnItemDataBound (и гнездо крысы проверки, является ли это правильным элементом, который нужно изменить).

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

То, что это случилось, используя <%%>, является просто корреляцией с природой classического ASP-спагетти, а не причинностью. Если вы придерживаетесь логики вашего представления к HTML / CSS / Javascript и минимальной логике, необходимой для презентации , остальное – синтаксис.

Сравнивая данный бит функциональности с WebForms, обязательно включите все созданные C конструктором C # и C # кода вместе с кодом .aspx, чтобы убедиться, что решение MVC на самом деле не является, по сути, намного проще ,

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

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

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

 <% if (Model.PreviousPost || Model.NextPost) { %> 
<% if (Model.PreviousPost) { %> <% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %> <% } if (Model.NextPost) { %> <% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %> <% } %>
<% } %>

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

ПРИМЕЧАНИЕ. ViewData.Model становится моделью в следующей версии.

И с помощью пользовательского контроля это станет

 <% Html.RenderPartial("Pager", Model.PagerData) %> 

где PagerData инициализируется через анонимный конструктор в обработчике действий.

edit: Мне любопытно, как будет выглядеть ваша реализация WebForm для этой проблемы.

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

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

MVC хочет получить контроль над веб-формами, работать в среде без состояния и реализовать шаблон проектирования Model View Controller без дополнительной работы, которая обычно выполняется при реализации этого шаблона.

Если вы хотите контролировать, очищать код и использовать шаблоны проектирования MVC, это для вас, если вам не нравится работать с разметкой, не заботятся о том, как неправильно сформирована ваша разметка, а затем использовать ASP.Net Web Forms.

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

EDIT Я также должен указать, что веб-формы и MVC имеют свое место, я никоим образом не утверждал, что один лучше, чем другой, только то, что каждый MVC имеет силу восстановить контроль над разметкой.

Я думаю, что вам не хватает некоторых вещей. Во-первых, нет необходимости в Response.Write, вы можете использовать tags <%= %> . Во-вторых, вы можете написать собственные расширения HtmlHelper для выполнения общих действий. В-третьих, немного форматирования помогает многое. В-четвертых, все это, вероятно, застряло бы в пользовательском элементе управления для совместного использования нескольких разных видов, и, таким образом, общая метка в главном представлении будет более чистой.

Я дам вам, что отметка все еще не такая аккуратная, как хотелось бы, но ее можно было бы значительно очистить за счет использования некоторых временных переменных.

Теперь, это не так плохо, и было бы еще лучше, если бы мне не пришлось отформатировать его для SO.

  <% var PreviousPost = ViewData.Model.PreviousPost; var NextPost = ViewData.Model.NextPost; // Display the "Next and Previous" links if (PreviousPost != null || NextPost != null) { %> 
<%= PreviousPost == null ? string.Empty : Html.ActionLinkSpan("<< " + PreviousPost.Subject, "view", new { id = PreviousPost.Id }, new { style = "float: left;" } ) %> <%= NextPost == null ? string.Empty : Html.ActionLinkSpan( NextPost.Subject + " >>", "view", new { id = NextPost.Id }, new { style = "float: right;" } ) %>
<% } %>

Большое дело с MVC заключается в том, что это концептуальная структура, которая существует уже давно, и зарекомендовала себя как продуктивный и мощный способ создания как веб-приложений, так и приложений рабочей станции, которые масштабируются горизонтально и вертикально. Он возвращается прямо к Альто и Smalltalk. Microsoft опаздывает на вечеринку. То, что мы имеем сейчас с ASP.NET MVC, действительно примитивно, потому что так много догоняют; но, черт возьми, они быстро и яростно выливают новые релизы.

Что было с Ruby on Rails? Rails – это MVC. Разработчики были преобразованы, потому что, из уст в уста, это стало способом для программистов быть продуктивными.

Это огромная сделка; MVC и неявное одобрение jQuery являются решающими моментами для Microsoft, принимающих нейтральную платформу. И что нейтрально об этом, так это то, что в отличие от веб-форм Microsoft не может заблокировать вас концептуально. Вы можете взять весь свой код C # и переопределить на другом языке полностью (скажем, PHP или java – вы его называете), потому что это концепция MVC, переносимая, а не сам код. (И подумайте, насколько огромным является то, что вы можете использовать свой дизайн и реализовать его как приложение для рабочей станции с небольшим изменением кода и без изменения дизайна. Попробуйте это с помощью Web Forms.)

Microsoft решила, что Web Forms не будет следующим VB6.

Пожалуйста, взгляните на сообщение Роба Конье, которое я ставлю, я просто скажу: вы должны учиться MVC

Двумя основными преимуществами структуры ASP.NET MVC над веб-формами являются:

  1. Возможность тестирования – пользовательский интерфейс и события в веб-формах практически невозможно тестировать. С ASP.NET MVC элементы управления тестированием блока и виды, которые они визуализируют, просты. Это связано с затратами на начальную стоимость разработки, но исследования показали, что это окупается в долгосрочной перспективе, когда приходит время рефакторировать и поддерживать приложение.
  2. Лучший контроль над отображаемым HTML. Вы заявляете, что вам не нужен обработанный HTML, потому что никто не смотрит на него. Это действительная жалоба, если это единственная причина для корректного форматирования HTML. Существует множество причин для должным образом отформатированного HTML, в том числе: SEO, возможность чаще использовать селектор идентификаторов (в css и javascript), меньшие отпечатки страниц из-за отсутствия viewstate и смехотворно длинных идентификаторов (ctl00_etcetcetc).

Теперь эти причины не делают ASP.NET MVC лучше или хуже, чем веб-формы в черно-белом виде. ASP.NET MVC имеет свои сильные и слабые стороны, как и веб-формы. Тем не менее, большинство жалоб на ASP.NET MVC, похоже, связано с отсутствием понимания того, как использовать его, а не из-за фактических недостатков в рамках. Причина, по которой ваш код не выглядит правильно или выглядит правильно, может быть вызвана тем, что у вас есть несколько лет опыта работы в веб-формах под вашим поясом и только 1-2 месяца опыта ASP.NET MVC.

Проблема здесь не в том, что ASP.NET MVC качается или отстой, это то, что он новый, и есть очень мало согласия относительно того, как правильно его использовать. ASP.NET MVC предлагает гораздо более мелкомасштабный контроль над тем, что происходит в вашем приложении. Это может сделать определенные задачи проще или сложнее в зависимости от того, как вы к ним подходите.

Эй, я боролся с переходом на MVC. Я абсолютно не поклонник classического ASP и MVC-рендеринга, который напоминает мне много тех дней. Тем не менее, чем больше я использую MVC, тем больше он растет на мне. Я являюсь разработчиком веб-форм (как и многие другие) и провел последние несколько лет, привыкнув к работе с datagrids и т. Д. С MVC, который отнят. HTML-помощники – это ответ.

Совсем недавно я потратил 2 дня, пытаясь найти лучший способ добавить пейджинг к «сетке» в MVC. Теперь, с веб-формами, я мог бы выгнать это в мгновение ока. Но я скажу это … как только у меня были classы вспомогательного помощника, созданные для MVC, это стало чрезвычайно простым в реализации. Для меня это даже проще, чем веб-формы.

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

Это смешно, потому что это то, что я сказал, когда впервые увидел веб-формы.

Я признаю, что пока не получил asp.net MVC. Я пытаюсь использовать его в стороннем проекте, который я делаю, но он идет довольно медленно.

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

До сих пор я заметил, что главной причиной использования MVC является полный контроль над вашим HTML. I also read that asp.net MVC is able to serve up more pages faster than web forms and probably related to this, the individual page size is smaller than an average web forms page.

I really don’t care what my HTML looks like as long as it works in the major browsers, but I do care how fast my pages load and how much bandwidth they take up.

While I fully agree that that is ugly markup, I think using the ugly view syntax to write off ASP.NET MVC as a whole is not fair. The view syntax has gotten the least attention from Microsoft, and I am fully expecting something to be done about it soon.

Other answers have discussed the benefits of MVC as a whole, so I will focus on the view syntax:

The encouragement to use Html.ActionLink and other methods that generate HTML is a step in the wrong direction. This smacks of server controls, and, to me, is solving a problem that doesn’t exist. If we are going to generate tags from code, then why bother using HTML at all? We can just use DOM or some other model and build up our content in the controller. Ok, that sounds bad, doesn’t it? Oh yes, separation of concerns, that is why we have a view.

I think the correct direction is to make the view syntax as much like HTML as possible. Remember, a well designed MVC should not only give you separation of code from content, it should let you streamline your production by having people who are expert in layout work on the views (even though they do not know ASP.NET), and then later as a developer you can step in and make the view mockup actually dynamic. This can only be done if if the view syntax looks very much like HTML, so that the layout folks can use DreamWeaver or whatever the current popular layout tool is. You might be building dozens of sites at once, and need to scale in this way for efficiency of production. Let me give an example of how I could see the view “language” working:

  sample previous subject   sample next subject  

Это имеет ряд преимуществ:

  • looks better
  • more concise
  • no funky context switching betwen HTML and <% %> tags
  • easy to understand keywords that are self-explanatory (even a non-programmer could do this – good for parallelization)
  • as much logic moved back into controller (or model) as possible
  • no generated HTML – again, this makes it very easy for someone to come in and know where to style something, without having to mess around with Html. методы
  • the code has sample text in it that renders when you load the view as plain HTML in a browser (again, good for layout people)

So, what exactly does this syntax do?

mvc:inner=”” – whatever is in the quotes gets evaluated and the inner HTML of the tag gets replaced with the resulting string. (Our sample text gets replaced)

mvc:outer=”” – whatever is in the quotes gets evaluated and the outer HTML of the tag gets replaced with the resulting string. (Again, sample text gets replaced.)

{} – this is used for inserting output inside of attributes, similar to <%= %>

mvc:if=”” – insde the qoutes is the boolean expression to be evaulated. The close of the if is where the HTML tag gets closed.

mvc:else

mcv:elseif=”” – …

mvc:foreach

Now, I can only speak for myself here:

IMO, if you’re a die-hard (anything) then conversion isn’t for you. If you love WebForms that’s because you can accomplish what you need to, and that’s the goal of any too.

Webforms does a good job of abstracting HTML from the developer . If that’s your goal, stick with Web Forms. You have all the wonderful “click and drag” functionality that has made desktop development what it is today. There are many included controls (plus a wealth of third party controls) that can bring about different functionality. You can drag a “grid” that’s directly associated with a DataSource from your database; it comes with built in inline-editing, paging, etc.

As of right now, ASP.NET MVC is very limited in terms of third party controls. So again, if you like Rapid Application Development, where a lot of functionality is wired up for you, you should not try to get converted.

With all of this said, this is where ASP.NET shines: – TDD. Code is not testable, nuff said.

  • Separation of concerns. That is the backbone of the MVC pattern. I am fully aware that you can accomplish this in Web Forms. However, I like imposed structure. It was too easy in Web Forms to mix design and logic. ASP.NET MVC makes it easier for different members of a team to work on different sections of the application.

  • Coming from somewhere else: My background is CakePHP and Ruby on Rails. So, it is clear where my bias lies. It’s simply about what you’re comfortable with.

  • Learning Curve: To expand on the last point; I hated the idea of “templating” to change the functionality of different elements. I didn’t like the fact that a lot of the design was accomplished in the code behind file. It was one more thing to learn, when I was already intimately familiar with HTML and CSS. If I want to do something in an “element” on the page, I stick in a “div” or “span”, slap an ID on it and off I go. In Web Forms I would have to go research how to do this.

  • Current State of Web “Design”: Javascript libraries like jQuery are becoming more commonplace. The way that Web Forms mangles your IDs just makes implementation (outside of Visual Studio) more difficult.

  • More Separation (Design): Because a lot of the design is wired into your controls, it would be very difficult for an outside designer (without Web Forms) knowledge to work on a Web Forms project. Web Forms was built to be the end all and be all.

Again, much of these reasons stem from my unfamiliarity with Web Forms. A Web Forms project (if designed right) can have “most” of the benefits of ASP.NET MVC. But that’s the caveat: “If designed right”. And that’s just something I don’t know how to do in Web Forms.

If you’re doing stellar work in Web Forms, you’re efficient and it works for you, that’s where you should stay.

Basically, do a quick review on both (try to find a unbiased source [good luck]) with a list of pros and cons, evaluate which one fit your goals and pick based on that.

Bottom line, pick the path of least resistance and most benefit to meet your goals. Web Forms is a very mature framework and will only get better in the future. ASP.NET MVC is simply another alternative (to draw in Ruby on Rails and CakePHP developers such as myself 😛 )

Java EE’s JSPs looked like this when they were first proposed – ugly scriptlet code.

Then they offered up tag libraries to make them more HTML tag-ish. The problem was that anybody could write a tag library. Some of the results were disastrous, because people embedded a lot of logic (and even style) into tag libraries that generated HTML.

I think the best solution is the JSP Standard Tag Library (JSTL). It’s “standard”, HTML tag-ish, and helps prevent people from putting logic into pages.

An added benefit is that it preserves that line of demarcation between web designers and developers. The good sites that I see are designed by people with an aesthetic sense and designing for usability. They lay out pages and CSS and pass them on to developers, who add in the dynamic data bits. Speaking as a developer who lacks these gifts, I think we give something important away when we ask developers to write web pages from soup to nuts. Flex and Silverlight will suffer from the same problem, because it’s unlikely that designers will know JavaScript and AJAX well.

If .NET had a path similar to JSTL, I’d advise that they look into it.

Just thought I’d share how this sample looks with the shiny new Razor view engine which is default since ASP .NET MVC 3.

 @{ var prevPost = ViewData.Model.PreviousPost; var nextPost = ViewData.Model.NextPost; } @if (prevPost != null || nextPost != null) { 
@if (prevPost != null) { @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id }) } @if (nextPost != null) { @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id }) }
}

Any problem with that?
Also, you shouldn’t actually inline your CSS styles, should you? And why do you check for nullity in three places instead of just two? An extra div rarely hurts. Вот как я это сделаю:

 
@if (prevPost != null) { @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id, @class = "prev-link" }) } @if (nextPost != null) { @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id, @class = "next-link" }) }

I can’t speak directly to the ASP.NET MVC project, but generally speaking MVC frameworks have come to dominate web application development because

  1. They offer a formal separation between Database Operations,”Business Logic”, and Presentation

  2. They offer enough flexibility in the view to allow developers to tweak their HTML/CSS/Javascript to work in multiple browsers, and future versions of those browsers

It’s this last bit that’s the important one. With Webforms, and similar technologies, you’re relying on your vendor to write your HTML/CSS/Javascript for you. It’s powerful stuff, but you have no guarantee that the current version of Webforms is going to work with the next generation of web browsers.

That’s the power of the view. You get full control over your application’s HTML. The downside is, you need to be disciplined enough to keep the logic in your views to a minimum, and keep the template code as simple as you possibly can.

So, that’s the trade-off. If Webforms are working for you and MVC isn’t, then keep using Webforms

Most of my frustration with it is just not knowing how to do things “properly”. Since it was released as a preview we’ve all had a bit of time to look at things, but they’ve been changing quite a bit. At first I was really frustrated but the framework seems workable enough to enable me to create extremely complex UI’s (read: Javascript) pretty quickly. I understand that you can do this with Webforms as I was doing it before but it was a huge pain in the butt trying to get everything to render correctly. A lot of times I would end up using a repeater to control the exact output and would end up with a lot of the spaghetti mess that you have above as well.

In an effort to not have the same mess, I’ve been using a combination of having domain, service layers, and a dto to transfer to the view. Put that together with spark, a view engine and it gets really nice. It takes a bit to setup but once you get it going, I’ve seen a big step up in the complexity of my applications visually, but its so stinking simple to do code wise.

I wouldn’t probably do it exactly like this but here’s your example:

  

That’s pretty maintainable, testable, and tastes yummy in my code soup.

The takeaway is that clean code is really possible, but it’s a big ass shift from the way we were doing things. I don’t think everyone groks it yet though. I know I’m still figuring it out…

Steve Sanderson’s recently published book ‘Pro ASP.NET MVC’ [1] [2] from Apress suggests another alternative — creating a custom HtmlHelper extension. His sample (from Chapter 4 on page 110) uses the example of a paged list, but it can easily be adapted for your situation.

 public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func pageUrl) { StringBuilder result = new StringBuilder(); if (previous != null || next != null) { result.Append("
"); if (previous != null) { result.Append(@""); TagBuilder link = new TagBuilder("a"); link.MergeAttribute("href", pageUrl(previous.Id)); link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject)); result.Append(link.ToString()); result.Append(""); } if (next != null) { if (previous != null) { result.Append(" "); } result.Append(@""); TagBuilder link = new TagBuilder("a"); link.MergeAttribute("href", pageUrl(next.Id)); link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject)); result.Append(link.ToString()); result.Append(""); } result.Append("
"); } return result.ToString(); }

You would call it in your view with code something like this:

 <%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %> 

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

I was hoping to see a post from Phil Haack, but it wasnt here so I just cut and paste it from http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should-learn-mvc/ in the comments section

Haacked – April 23, 2009 – Rob, you’re a riot! 🙂 I do find it funny when people write spaghetti code in MVC and then say “look! Spaghetti!” Hey, I can write spaghetti code in Web Forms too! I can write it in rails, PHP, Java, Javascript, but not Lisp. But only because I can’t yet write anything in Lisp. And when I do write spaghetti code I don’t look at my plate glumly expecting to see macaroni. The point people often make when comparing it to classic ASP is that with classic ASP people tended to mix concerns. Pages would have view logic with user input handling mixed in with model code and business logic all mixed up in one. That’s what the spaghetti was about! Mixing concerns all in one big mess. With ASP.NET MVC, if you follow the pattern, you’re less likely to do it. Yeah, you still might have a bit of code in your view, but hopefully that’s all view code. The pattern encourages you to not put your user interaction code in there. Put it in the controller. Put your model code in a model class. Там. No spaghetti. It’s O-Toro Sushi now. 🙂

Me too; I would spend my time on Silverlight rather than ASP.NET MVC. I have tried MVC 1.0 and have had a look at the latest 2.0 Beta 1 release a few day ago.

I (can)’t feel that how ASP.NET MVC is better than webform. The selling point of MVC are:

  1. Unit (test)
  2. Separate the design (view) and logic (controller + model)
  3. No viewstate and better element id management
  4. RESTful URL and more …

But webform, by using code-behind.Theme, Skin, and Resource are already perfect to separate the design and logic.

Viewstate: client id management is coming on ASP.NET 4.0. I am only concerned about unit tests, but unit tests are not enough being a reason to turn me to ASP.NET MVC from webform.

Maybe I can say: ASP.NET MVC is not bad, but webform is already enough.

I’ve been using MVC for since Preview 3 came out and while it is still has it’s growing pains it helps quite a bit in the area of team development. Try having three people work on a single webforms page and then you’ll understand the concept of banging your head on the wall. I can work with a developer who understands the design elements on the view page and our resident Linq god in making the model work while I put everything together in the controller. I’ve never been able to develop in a realm where the separation of concerns was so easy to achieve.

Biggest selling point of ASP.Net MVC – StackOverflow runs on the MVC stack.

That being said… your code is so much prettier than what I normally do with the view page. Also, one of the guys I work with is working on wrapping the HTML helper into a tag library. Instead of <%=Html.RandomFunctionHere() %> it works like

< hh:randomfunction / >

I just hope the MVC team gets around to it at some point because I’m sure they’d do a better job of it.

Use a Facade Pattern to wrap all the logic for all the data you need to display and then use it as your generic in your view and then…. no more spaghetti code. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

If you need more help [email protected]

The implementation ASP.NET MVC is horrible. The product plain sucks. I’ve seen several demos of it and I’m ashamed of MSFT… I’m sure the guys who wrote it are smarter than me, but it’s almost as if they don’t know what the Model-View-Controller is.

The only people I know who are trying to implement MVC are people who like to try new things from MSFT. In the demos I’ve seen, the presenter had an apologetic tone…

I’m a big fan of MSFT, but I have to say that I see no reason to bother with their implementation of MVC. Either use Web Forms or use jquery for web development, don’t choose this abomination.

РЕДАКТИРОВАТЬ:

The intent of the Model-View-Controller architectural design pattern is to separate your domain from the presentation from the business rules. I’ve used the pattern successfully in every Web Forms project I’ve implemented. The ASP.NET MVC product does not lend itself well to the actual architectural design pattern.

  • Передача массива в mvc Действие через AJAX
  • Asp.Net MVC3: установка пользовательского IServiceProvider в ValidationContext, поэтому валидаторы могут разрешать услуги
  • Веб-API и ValidateAntiForgeryToken
  • Как расширить доступные свойства User.Identity
  • Как найти абсолютный URL-адрес действия в ASP.NET MVC?
  • Почему Html.ActionLink визуализирует «Длина = 4»
  • Использует ViewBag в MVC плохо?
  • Как заблокировать пути в ASP.NET MVC?
  • подтвердите выпадающий список в asp.net mvc
  • Объединение ASP.Net MVC с WebForms
  • Что означает, что свойство должно быть и значение NULL?
  • Interesting Posts

    Вызовите функции Go из C

    Пользовательская панель инструментов XP

    Как поменять клавиши Alt и Windows с помощью xmodmap?

    Как очистить / что делать с получением жидкой формы очистителя сжатого воздуха на компьютерном оборудовании?

    Скрытие адреса электронной почты в Windows 8

    отказоустойчивый плагин не будет работать в одном проекте, но будет работать на другом – почему?

    Как подключиться к веб-серверу, работающему на виртуальной машине, когда виртуальная машина находится в режиме NAT?

    Что такое нормальная / безопасная температура для i7 2600K CPU?

    ViewController.Type не имеет члена с именем

    Как перебирать cin по строкам в C ++?

    Загрузочный стол с полосками: как изменить цвет фона полосы?

    Получите IPrincipal от токена носителя OAuth в OWIN

    Ошибка генериков: ожидаемый тип параметра, найденная структура

    как изменить текст в Android TextView

    Как использовать тип: «POST» в jsonp ajax call

    Давайте будем гением компьютера.