Кто-нибудь, кроме меня, просто НЕ получает ASP.NET MVC? [закрыто]

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

Например, я скачал бета-версию 1 и собираю с ней небольшой личный сайт / резюме / блог. Вот фрагмент из представления 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 для этого?

Изменить: полужирным шрифтом выделена строка «temp Html / css», чтобы люди знали об этом.

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

Веб-формы

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

MVC

MVC использует более «архитектурный» взгляд на разработку веб-приложений: предлагает стандартизованный каркас, на котором можно строить. Он также предоставляет инструменты для автоматического создания классов моделей, представлений и контроллеров в рамках установленной архитектуры. Например, как в Ruby on Rails (далее просто «Rails»), так и в ASP.NET MVC вы всегда будете начинать со структуры каталогов, которая отражает их общую модель архитектуры веб-приложений. Чтобы добавить представление, модель и контроллер, вы будете использовать команду наподобие Rails "Rails script / generate scaffold {modelname}" (ASP.NET MVC предлагает аналогичные команды в IDE). В результирующем классе контроллера будут методы («Действия») для Index (показать список), Show, New и Edit и Destroy (по крайней мере, в Rails, MVC аналогичен). По умолчанию эти "

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

Сравнение

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

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

Во-первых, хотя запустить демонстрационный сайт несложно, общая архитектурная модель требует значительного обучения. Когда они говорят: «Соглашение важнее конфигурации», это звучит хорошо - до тех пор, пока вы не поймете, что вам нужно выучить соглашение, равное книге. Кроме того, часто немного ум , чтобы понять, что происходит , потому что вы будете полагаться на магии , а не явные вызовов. Например, что «Return View ();» позвонить выше? Точно такой же вызов можно найти в других действиях, но они идут в разные места. Если вы понимаете соглашение MVCтогда вы знаете, почему это делается. Тем не менее, это, конечно, не квалифицируется как пример хорошего именования или легко понятного кода, и новичкам намного сложнее подобрать его, чем веб-формы (это не просто мнение: в прошлом году у меня был летний стажер, изучавший веб-формы. и MVC в этом году, и разница в производительности была явной - в пользу веб-форм). Кстати, 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, чем элементы управления веб-форм. Однако ASP.NET 4.0 предоставляет возможность давать имена элементам управления и, таким образом, в значительной степени устраняет это преимущество.

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

Выводы

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

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

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

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

Что касается тех, кто видел в этом религиозную битву и кто безжалостно спровоцировал наводнения против голосов, я не понимаю, почему вы беспокоитесь (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, который просто перемещает большую часть классического уродства ASP в файл кода программной части.

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

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

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

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

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

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

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

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

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

ПРИМЕЧАНИЕ: ViewData.Model становится Model в следующем выпуске.

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ Я также должен заявить, что веб-формы и MVC имеют свое место, я никоим образом не утверждал, что один был лучше другого, только то, что каждый MVC имеет силу восстановления контроля над разметкой.

Я думаю, тебе чего-то не хватает. Во-первых, Response не нужен. Запишите, вы можете использовать <%= %>теги. Во-вторых, вы можете написать свои собственные расширения 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>

  <% } %>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пока что я заметил, что главная причина использовать MVC - получить полный контроль над вашим HTML. Я также читал, что asp.net MVC может обслуживать больше страниц быстрее, чем веб-формы, и, вероятно, в связи с этим размер отдельной страницы меньше, чем средняя страница веб-форм.

Меня действительно не волнует, как выглядит мой HTML, пока он работает в основных браузерах, но меня волнует, как быстро загружаются мои страницы и сколько полосы пропускания они занимают.

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

В других ответах обсуждались преимущества MVC в целом, поэтому я сосредоточусь на синтаксисе представления:

Поощрение к использованию Html.ActionLink и других методов, генерирующих HTML, является шагом в неверном направлении. Это попахивает средствами управления сервером и, на мой взгляд, решает проблему, которой не существует. Если мы собираемся генерировать теги из кода, тогда зачем вообще использовать HTML? Мы можем просто использовать DOM или какую-то другую модель и создавать наш контент в контроллере. Хорошо, это звучит плохо, не так ли? Ах да, разделение интересов, поэтому у нас есть точка зрения.

Я думаю, что правильное направление - сделать синтаксис представления максимально похожим на HTML. Помните, что хорошо спроектированный MVC должен не только отделять код от содержимого, но и позволять оптимизировать производство за счет того, что над представлениями работают специалисты по макетированию (даже если они не знают ASP.NET), а затем позже, как разработчик, вы можете вмешаться и сделать макет представления действительно динамичным. Это можно сделать только в том случае, если синтаксис представления очень похож на HTML, так что люди, занимающиеся компоновкой, могут использовать DreamWeaver или любой другой популярный в настоящее время инструмент компоновки. Возможно, вы одновременно создаете десятки сайтов, и вам необходимо масштабировать таким образом для повышения эффективности производства. Позвольте мне привести пример того, как я могу увидеть, как работает "язык" представления:

<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;" />

Это дает несколько преимуществ:

• выглядит лучше
• более лаконичный
• нет фанкового переключения контекста между тегами HTML и <%%>
• простые для понимания ключевые слова, которые не требуют пояснений (это может сделать даже непрограммист - хорошо для распараллеливания)
• как можно больше логики перемещено обратно в контроллер (или модель)
• нет сгенерированного HTML - опять же, это позволяет кому-то войти и узнать, где что-то стилизовать, без необходимости возиться с Html. методы
• в коде есть образец текста, который отображается, когда вы загружаете представление как простой HTML в браузере (опять же, хорошо для людей, занимающихся компоновкой)

Итак, что именно делает этот синтаксис?

mvc: inner = "" - все, что находится в кавычках, оценивается, и внутренний HTML-код тега заменяется полученной строкой. (Наш образец текста заменен)

mvc: outer = "" - все, что находится в кавычках, оценивается, и внешний HTML тега заменяется результирующей строкой. (Опять же, образец текста заменяется.)

{} - используется для вставки вывода внутри атрибутов, аналогично <% =%>

mvc: if = "" - inde the qoutes - это логическое выражение, которое нужно вычислить. Закрытие if - это место, где закрывается HTML-тег.

mvc: else

mcv: elseif = "" - ...

mvc: foreach

Теперь я могу говорить здесь только за себя:

ИМО, если вы упорны (что угодно), то конверсия не для вас. Если вы любите WebForms, это потому, что вы можете делать то, что вам нужно, и это тоже цель.

Webforms отлично абстрагирует HTML от разработчика . Если это ваша цель, придерживайтесь веб-форм. У вас есть все замечательные функции «щелкни и перетащи», которые сделали настольную разработку тем, чем она является сегодня. Есть много включенных элементов управления (плюс множество сторонних элементов управления), которые могут обеспечивать различную функциональность. Вы можете перетащить «сетку», которая напрямую связана с источником данных из вашей базы данных; он поставляется со встроенным редактированием, разбиением по страницам и т. д.

На данный момент ASP.NET MVC очень ограничен с точки зрения сторонних элементов управления. Итак, опять же, если вам нравится быстрая разработка приложений, в которой для вас настроено множество функций, вам не следует пытаться конвертироваться.

С учетом всего вышесказанного, вот где сияет ASP.NET: - TDD. - Код не поддается проверке, - сказал Нафф.

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

• Источник откуда-то еще: мой опыт - CakePHP и Ruby on Rails. Итак, ясно, в чем моя предвзятость. Дело просто в том, что вам удобно.

• Кривая обучения: развернуть последнюю точку; Мне не нравилась идея «шаблонов» для изменения функциональности различных элементов. Мне не нравился тот факт, что большая часть дизайна была реализована в коде файла. Это была еще одна вещь, которую нужно было изучить, когда я уже хорошо знал HTML и CSS. Если я хочу сделать что-то в «элементе» на странице, я вставляю «div» или «span», прикрепляю к нему идентификатор и ухожу. В веб-формах мне пришлось бы исследовать, как это сделать.

• Текущее состояние веб-дизайна: библиотеки Javascript, такие как jQuery, становятся все более обычным явлением. То, как Web Forms искажает ваши идентификаторы, только усложняет реализацию (за пределами Visual Studio).

• Больше разделения (дизайн): поскольку большая часть дизайна связана с вашими элементами управления, внешнему дизайнеру (без знаний веб-форм) будет очень сложно работать над проектом веб-форм. Веб-формы были созданы для того, чтобы быть всем и вся.

Опять же, многие из этих причин связаны с моим незнанием веб-форм. Проект веб-форм (если он правильно спроектирован) может иметь «большинство» преимуществ ASP.NET MVC. Но это нюанс: «Если правильно спроектирован». И это то, что я не умею делать в веб-формах.

Если вы отлично работаете в веб-формах, вы эффективны, и это работает на вас, вот где вам следует остановиться.

По сути, сделайте быстрый обзор обоих (попробуйте найти беспристрастный источник [удачи]) со списком плюсов и минусов, оцените, какой из них соответствует вашим целям, и выберите на основе этого.

В итоге выберите путь наименьшего сопротивления и наибольшую выгоду для достижения своих целей. Веб-формы - это очень зрелая среда, и в будущем она будет только улучшаться. ASP.NET MVC - просто еще одна альтернатива (для рисования на Ruby on Rails и разработчиков CakePHP, таких как я: P)

JSP Java EE выглядели так, когда они были впервые предложены - уродливый код скриптлета.

Затем они предложили библиотеки тегов, чтобы сделать их более похожими на теги HTML. Проблема заключалась в том, что любой мог написать библиотеку тегов. Некоторые результаты были катастрофическими, потому что люди встраивали много логики (и даже стиля) в библиотеки тегов, которые генерировали HTML.

Я думаю, что лучшим решением является стандартная библиотека тегов JSP (JSTL). Это «стандартный» HTML-тэг, который помогает предотвратить размещение логики на страницах.

Дополнительным преимуществом является то, что он сохраняет границу между веб-дизайнерами и разработчиками. Хорошие сайты, которые я вижу, созданы людьми с эстетическим чутьем и удобством использования. Они размещают страницы и CSS и передают их разработчикам, которые добавляют биты динамических данных. Как разработчик, которому не хватает этих способностей, я думаю, что мы отдаем нечто важное, когда просим разработчиков писать веб-страницы от супа до орехов. Flex и Silverlight столкнутся с той же проблемой, потому что маловероятно, что дизайнеры будут хорошо знать JavaScript и AJAX.

Если бы у .NET был путь, аналогичный JSTL, я бы посоветовал им изучить его.

Просто подумал, что я поделюсь, как этот образец выглядит с новым блестящим движком просмотра Razor, который используется по умолчанию с 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>
}

Есть проблемы с этим?
Кроме того, вам не следует встраивать свои стили CSS, не так ли? И почему вы проверяете аннулирование в трех местах, а не только в двух? Экстра divредко болит. Вот как бы я это сделал:

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

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

1. Они предлагают формальное разделение между операциями с базой данных, «бизнес-логикой» и презентацией.

2. Они предлагают достаточную гибкость в представлении, чтобы позволить разработчикам настраивать свои HTML / CSS / Javascript для работы в нескольких браузерах и будущих версиях этих браузеров.

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

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

Итак, это компромисс. Если веб-формы работают на вас, а MVC - нет, продолжайте использовать веб-формы.

Больше всего меня это раздражает, потому что я просто не знаю, как делать вещи «должным образом». С тех пор, как он был выпущен в качестве предварительного просмотра, у всех было немного времени, чтобы посмотреть на вещи, но они немного изменились. Сначала я был очень расстроен, но фреймворк кажется достаточно работоспособным, чтобы позволить мне довольно быстро создавать чрезвычайно сложные пользовательские интерфейсы (читай: Javascript). Я понимаю, что вы можете сделать это с помощью Webforms, как я делал это раньше, но это было огромной головной болью, пытаясь заставить все работать правильно. Много раз я в конечном итоге использовал повторитель для управления точным выходом и в конечном итоге получал много спагетти, что и у вас выше.

Чтобы не иметь такого же беспорядка, я использовал комбинацию наличия домена, уровней обслуживания и dto для передачи в представление. Совместите это с Spark, движком просмотра, и это станет действительно здорово. Это займет немного времени, но как только вы начнете работать, я увидел большой шаг вперед в сложности моих приложений визуально, но это так вонючая простота в написании кода.

Я бы, наверное, не стал делать это именно так, но вот ваш пример:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

Это довольно удобно в обслуживании, тестировании и вкусно в моем супе кода.

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

В недавно опубликованной книге Стива Сандерсона «Pro ASP.NET MVC» [1] [2] от Apress предлагается другая альтернатива - создание собственного расширения HtmlHelper. В его примере (из главы 4 на странице 110) используется пример постраничного списка, но его можно легко адаптировать к вашей ситуации.

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();
}

Вы бы назвали это в своем представлении кодом примерно так:

<%= 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

Я надеялся увидеть сообщение от Фила Хаака, но его здесь не было, поэтому я просто вырезал и вставил его из http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / в разделе комментариев

Haacked - 23 апреля 2009 г. - Роб, ты бунтарь! :) Мне действительно смешно, когда люди пишут код спагетти в MVC, а затем говорят: «Смотри! Спагетти!» Эй, я тоже умею писать спагетти-код в веб-формах! Я могу писать это на рельсах, PHP, Java, Javascript, но не на Лиспе. Но только потому, что я еще ничего не могу написать на Лиспе. И когда я пишу код для спагетти, я не смотрю на тарелку, мрачно ожидая увидеть макароны. Сравнивая его с классическим ASP, люди часто обращают внимание на то, что с классическим ASP люди склонны смешивать проблемы. Страницы будут иметь логику представления с обработкой пользовательского ввода, смешанную с кодом модели и бизнес-логикой, смешанными в одном. Вот о чем были спагетти! Смешивание проблем в одном большом беспорядке. С ASP.NET MVC, если вы будете следовать шаблону, у вас меньше шансов это сделать. Да уж, у вас все еще может быть немного кода в вашем представлении, но, надеюсь, это весь код просмотра. Шаблон поощряет вас не помещать туда код взаимодействия с пользователем. Вставьте его в контроллер. Поместите код своей модели в класс модели. Там. Никаких спагетти. Теперь это О-Торо Суши. :)

Я тоже; Я бы тратил время на Silverlight, а не на ASP.NET MVC. Я пробовал MVC 1.0 и несколько дней назад взглянул на последнюю версию 2.0 Beta 1.

Я не чувствую, насколько ASP.NET MVC лучше, чем веб-форма. Смысл продажи MVC:

1. Модульный тест)
   
2. Разделить дизайн (вид) и логику (контроллер + модель)
   
3. Нет состояния просмотра и улучшенное управление идентификаторами элементов
   
4. URL RESTful и многое другое ...

Но веб-форма с использованием кода программной части. Тема, скин и ресурс уже идеально подходят для разделения дизайна и логики.

Viewstate: управление идентификаторами клиентов входит в ASP.NET 4.0. Меня беспокоят только модульные тесты, но модульных тестов недостаточно, чтобы обратить меня на ASP.NET MVC из веб-формы.

Может быть, я могу сказать: ASP.NET MVC - это неплохо, но веб-формы уже достаточно.

Я использую MVC с тех пор, как вышел Preview 3, и, хотя он все еще болит, он немного помогает в области командной разработки. Попробуйте попросить трех человек работать над одной страницей веб-форм, и тогда вы поймете, как биться головой об стену. Я могу работать с разработчиком, который понимает элементы дизайна на странице просмотра, и нашим постоянным богом Linq, чтобы заставить модель работать, пока я собираю все вместе в контроллере. Мне никогда не удавалось развиваться в сфере, где было бы так легко разделить проблемы.

Самая большая точка продажи ASP.Net MVC - StackOverflow работает в стеке MVC.

При этом ... ваш код намного красивее, чем то, что я обычно делаю со страницей просмотра. Кроме того, один из парней, с которыми я работаю, работает над переносом помощника HTML в библиотеку тегов. Вместо <% = Html.RandomFunctionHere ()%> он работает как

<чч: случайная функция />

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

Используйте шаблон фасада, чтобы обернуть всю логику для всех данных, которые вам нужно отобразить, а затем использовать его в качестве общего в своем представлении, а затем ... больше никакого спагетти-кода. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Если вам нужна дополнительная помощь, cgardner2020@gmail.com

Реализация ASP.NET MVC ужасна. Продукт просто отстой. Я видел несколько его демонстраций, и мне стыдно за MSFT ... Я уверен, что парни, написавшие его, умнее меня, но это почти как если бы они не знали, что такое Model-View-Controller .

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

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

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

Цель шаблона архитектурного проектирования модель-представление-контроллер - отделить ваш домен от представления и бизнес-правил. Я успешно использовал этот шаблон во всех реализованных мной проектах веб-форм. Продукт ASP.NET MVC плохо подходит для реального архитектурного шаблона проектирования.