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

Я работаю с 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 для этого?

Изменить: Выделил строку "temp Html/css", чтобы люди могли ее прочесть.

Ответ 1

По сравнению с веб-формами 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", и вернитесь к индексу или Show).

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

Ответ 2

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

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

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

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

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

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

[Обновление]

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

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... и так далее...

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

Ответ 3

Большинство возражений против 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 конструктором С# и код С# вместе с кодом .aspx, чтобы убедиться, что решение MVC на самом деле нет, на самом деле, намного проще.

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

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

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

Ответ 4

<% 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 становится моделью в следующей версии.

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

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

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

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

Ответ 5

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

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

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

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

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

ИЗМЕНИТЬ Я также должен указать, что веб-формы и MVC имеют свое место, я никоим образом не заявлял, что один лучше, чем другой, только то, что каждый MVC имеет силу восстановить контроль над разметкой.

Ответ 6

Я думаю, что вам не хватает некоторых вещей. Во-первых, нет необходимости в 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>

  <% } %>

Ответ 7

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

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

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

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

Ответ 9

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

  • Testability. Пользовательский интерфейс и события в веб-формах практически невозможно тестировать. С ASP.NET MVC элементы управления тестированием блока и виды, которые они визуализируют, просты. Это связано с затратами на начальную стоимость разработки, но исследования показали, что это окупается в долгосрочной перспективе, когда приходит время рефакторировать и поддерживать приложение.
  • Лучший контроль над отображаемым 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 предлагает гораздо более мелкомасштабный контроль над тем, что происходит в вашем приложении. Это может сделать определенные задачи проще или сложнее в зависимости от того, как вы к ним подходите.

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

Хотя я полностью согласен с тем, что это уродливая разметка, я думаю, что использование уродливого синтаксиса представления для списания 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;" />

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

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

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

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

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

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

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

MVC: еще

mcv: elseif = "" -...

MVC: Еогеасп

Ответ 14

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

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

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

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

При этом все это говорит о том, как выглядит ASP.NET:  - TDD. Код не проверяется, сказал он.

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

  • Прибытие из другого места: мой фон - CakePHP и Ruby on Rails. Итак, ясно, где лежит мое предубеждение. Это просто о том, с чем вам удобно.

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

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

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

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

Если вы делаете звездную работу в Web Forms, вы эффективны, и она работает для вас, где вы должны остаться.

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

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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

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

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

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

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

Ответ 17

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

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

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

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

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

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

Ответ 18

Стив Сандерсон недавно опубликовал книгу "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

Ответ 19

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

Ответ 20

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

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

Ответ 21

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

I (может) не чувствовать, что ASP.NET MVC лучше, чем веб-форма. Пункт продажи MVC:

  • Единица (тест)
  • Отделить дизайн (представление) и логику (контроллер + модель)
  • Отсутствие управления представлением и улучшением элемента id
  • URL RESTful и многое другое...

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

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

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

Ответ 22

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

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

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

< hh: randomfunction/" >

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

Ответ 23

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

Если вам нужна дополнительная помощь [email protected]

Ответ 24

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

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

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

EDIT:

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