asp.net-mvc - книга - asp net mvc example



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

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

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

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

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

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

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

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

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


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, который просто переносит большую часть классического ASP-уродства в файл кода.

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

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

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

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

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

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

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


Двумя основными преимуществами структуры 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 одновременно является подходом более низкого уровня к генерации HTML с большим контролем над выходом страницы и более высокоуровневым, более архитектурным подходом. Позвольте мне захватить веб-формы и MVC и показать, почему я думаю, что сравнение благоприятствует веб-формам во многих ситуациях - до тех пор, пока вы не попадете в некоторые классические ловушки веб-форм.

Веб-формы

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

MVC

MVC использует более «архитектурный» вид разработки веб-приложений: предлагая стандартизованные леса для построения. Он также предоставляет инструменты для автоматического создания классов моделей, представлений и контроллеров в рамках установленной архитектуры. Например, в Ruby on Rails (только здесь «Rails») и ASP.NET MVC вы всегда начинаете с структуры каталогов, которая отражает их общую модель архитектуры веб-приложений. Чтобы добавить представление, модель и контроллер, вы будете использовать такую ​​команду, как Rails «Rails script / generate scaffold {modelname}» (ASP.NET MVC предлагает аналогичные команды в среде IDE). В результирующем классе контроллера будут найдены методы («Действия») для 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 подразумевает, что вы создаете классический веб-сайт в стиле 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, все текущие усилия, которые я видел, страдают от необходимости создавать (несколько громоздкий) код для привязки этих элементов управления к классу 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 действительно не отвечает на звонок для меня. Итак, сердечное «спасибо» людям, которые предоставили разумные критические замечания по моему первоначальному ответу.

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

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


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

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

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


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

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

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

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= 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;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

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


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. There. No spaghetti. It's O-Toro Sushi now. :)


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 - 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.


It's funny because that's what I said when I first saw webforms.


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) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

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. Вот как я это сделаю:

<div>
    @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" })
    }
    <div class="clear" />
</div>

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.


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 :P )


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<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            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("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            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("</span>");
        }

        result.Append("</div>");
    }

    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]

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



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:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

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

  • 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. methods
  • 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





asp.net-mvc