ASP.NET MVC> ASP.NET WebForms, почему?

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

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

Веб-формы Просмотр кода:

//UI
<h2><asp:Label ID="lblPageHeader" runat="server" /></h2>

Код веб-форм:

//CODE BEHIND
this.lblPageHeader.Text = myObject.Header;

Просмотр кода MVC:

//UI
<h2><%= Html.Encode(Model.PageTitle) %></h2>

Код контроллера MVC:

index = new Index
{
    PageText = sb.ToString(),
    PageTitle = "WELCOME"
};
return View(index);

Опять же, я могу быть упрямым, но одна из вещей, которые мне очень нравятся в WebForms, - это легкость в настройке свойств объекта, таких как DataSources и Text. Похоже, что это совсем другое в MVC и менее читаемо, что заставляет меня задуматься о долгосрочном обслуживании.

ИЗМЕНИТЬ Изучив типизированные модели, я думаю, что читаемость кода значительно улучшилась.

Ответ 1

Я бы написал:

<h2><%= Html.Encode(Model.Title) %></h2>

(возможно с помощью типизированных представлений)

вместо

<h2><%= Html.Encode((MyApp.MyObject)ViewData["PageObject"].Header) %></h2>

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

Ответ 2

Что хорошего в ASP.NET MVC, это не попытка скрыть, как работает HTTP. Чтобы полностью понять ASP.NET MVC, вам нужно понять технологии Интернета.

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

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

С ASP.NET MVC вся эта глупость покончена. Вы не защищены от HTTP, HTML, CSS или JavaScript - если вы придете на вечеринку с этими технологиями, структура уберется от пути и позволит вам использовать их. Если нет, то, к счастью, он не пытается помочь вам притвориться, что их не существует.

Ответ 3

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

Теперь MVC не для всех. Вы можете захотеть просмотреть MVP (Model-View Presenter) для форм ASP.NET, поскольку использует очень похожие концепции MVC, за исключением того, что Presenter контролирует изменение внутренних элементов представления.

Но тестируемость - действительно большой плюс для тестирования вашего кода. Например, whawt происходит, когда кто-то нажимает на метод/действие ChangePassword:

[TestClass]
public class AccountControllerTest
{

    [TestMethod]
    public void ChangePasswordPostRedirectsOnSuccess()
    {
        // Arrange
        AccountController controller = GetAccountController();

        // Act
        RedirectToRouteResult result = 
            (RedirectToRouteResult)controller.ChangePassword(
                "oldPass", "newPass", "newPass");

        // Assert
        Assert.AreEqual("ChangePasswordSuccess"
            , result.RouteValues["action"]);
    }
}

Ответ 4

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

MVC потребует от вас лучшего знания основных арендаторов веб-разработки (GET, POST, REQUEST, HTML, CSS, JAVASCRIPT), результат будет намного лучше. Смотрите мой график того, как я думаю, MVC работает:-)

alt text http://www.baseestate.com/webformsmvc.gif

Ответ 5

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

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

Ответ 6

Верно, что вам нужно сделать больше в MVC, чтобы получить некоторые из тех же основных ОЧЕНЬ автоматической функциональности, с которой вы привыкли в WebForms.

Однако в конечном итоге вы получите больше контроля.

главное, что связано с WebForms - это весь сценарий PostBack, и сколько обручей вам нужно перепрыгнуть, чтобы реализовать что-то простое WebForms, о котором не подумали. Один прекрасный пример - мой вопрос, связанный с WebForms: Есть ли какой-либо родной способ в ASP.NET для создания сообщения об успешном завершении?

Я хотел сделать сообщение "Запись сохранена" или "Новая запись добавлена" в приложении WebForms. Оказывается, вам нужно сделать некоторые действительно страшные вещи только для того, чтобы заставить эту простую функциональность работать, потому что у них нет обычного способа сделать это в WebForms, и чтобы сделать собственный метод, вы боретесь с скрытая функциональность в PostBack.

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

Ответ 7

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

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

Я также очень люблю WebForms. Я также не любил первые несколько недель/месяцев MVC по тем же причинам, которые вы выдвинули. После того, как я сделал некоторую кодировку и смог сравнить опыт, я начал наслаждаться MVC.

Тем не менее, есть некоторые области, где подход MVC будет намного сложнее и создать больше беспорядка, чем WebForms.

Это придет со временем. Не очень долго.:)

Ответ 8

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

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

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

Ответ 9

Я думаю, это очень зависит от вашего фона. Если вы уже знакомы с чем-то вроде Ruby-rails и/или Django, asp.net mvc имеет гораздо больше смысла.

Также, если вы долгое время занимались веб-сайтами в Html и css, Mvc намного лучше, так как вы полностью контролируете свой вывод html.

Если вам удобно с asp.net, просто продолжайте использовать это, это не уходит:).