ASP.NET MVC> ASP.NET WebForms, почему? - PullRequest
13 голосов
/ 06 апреля 2009

Я завершил свое первое веб-приложение, используя 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 это совсем другое и менее читабельное, что заставляет меня задуматься о долгосрочном обслуживании.

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

Ответы [ 9 ]

14 голосов
/ 06 апреля 2009

ASP.NET MVC Best Practices, Советы и хитрости

Я бы написал:

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

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

вместо

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

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

10 голосов
/ 06 апреля 2009

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

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

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

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

8 голосов
/ 07 апреля 2009

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

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

альтернативный текст http://www.baseestate.com/webformsmvc.gif

8 голосов
/ 06 апреля 2009

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

Теперь, MVC не для всех. Возможно, вы захотите взглянуть на MVP (Presenter Model-View) для ASP.NET Forms, поскольку он использует очень похожие концепции 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"]);
    }
}
2 голосов
/ 06 апреля 2009

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

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

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

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

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

2 голосов
/ 06 апреля 2009

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

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

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

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

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

2 голосов
/ 06 апреля 2009

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

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

0 голосов
/ 07 апреля 2009

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

Кроме того, если вы долгое время работали с сайтами на HTML и CSS, Mvc намного лучше, так как вы полностью контролируете вывод HTML.

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

0 голосов
/ 06 апреля 2009

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...