Почему ASP.NET MVC поверх Web-форм Asp.NET

Я разработчик asp.net Web Forms, и я знаю основы Asp.net MVC. Разработчики говорят о преимуществах MVC, но я не нашел четкого или убедительного описания для использования MVC над Asp.NET.

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

Я знаю, что вы не можете заменить Asp.NET Web Forms с помощью Asp.NET MVC, но у нас есть следующие преимущества в MVC:

  • Разделение проблем (SoC). Мы можем достичь этого в asp.net также, добавив компонент BAL на самом деле в MVC, нам нужно изолировать бизнес-логику от методов действий контроллера. для разделения Model-View-Controller в MVC? то как насчет бизнес-логики. Просьба представить пример реальной жизни, который рассмотрит как веб-формы, так и MVC.
  • Включить полный контроль над отображаемым HTML. Веб-формы также обеспечивают контроль над Html, не так ли? Считается, что html-рендеринг в Web Forms более абстрагируется, чем то, что делает html-помощники в MVC. Кто-нибудь, пожалуйста, объясните это примером, рассматривающим как Web Forms, так и MVC, поскольку я становлюсь более смущенным в этой точке.
  • Включить тестовую разработку (TDD). Если вы разделили свою бизнес-логику на BAL, то вы достигли TDD? Есть ли сценарий, в котором MVC будет точным выбором по веб-формам? Просьба привести пример для тех же
  • Нет событий ViewState и PostBack. Мы можем управлять представлением в Web Forms, которое связано со стоимостью усилий, поскольку в MVC мы можем поддерживать состояние с помощью Viewbag, Tempdata, поскольку веб-апатрид существует, есть какой-то механизм что MVC сохраняет свое состояние как скрытые поля для Web Forms, а затем как MVC улучшает производительность и размер страницы с точки зрения statefullness? Пример с учетом оценки веб-форм и MVC.
  • Простая интеграция с jQuery: "Asp.NET Web Forms генерирует свой собственный идентификатор для элементов управления", это единственное соображение для удобства интеграции фреймворков JavaScript? если да, то мы можем использовать ClientIDMode в элементе управления asp.net в веб-формах

Ответ 1

1. Разделение проблем

SoC в MVC - это не разделение бизнес-логики с пользовательским интерфейсом. Что еще более важно, он дает основные функции контроллера:

  • чтобы заполнить модель модели из модели домена;
  • для просмотра активности вида;
  • для отображения представлений в зависимости от логики домена.

Вид отвечает только за представление данных в MVC.

Это делает тестирование очень простым, поскольку контроллер работает с чистыми классами Model Model, в отличие от WebForms, который управляет событиями и формой.

В WebForms View обрабатывается вся активность пользовательского интерфейса и в основном принимает решения о потоке сценариев.

Здесь я хотел бы упомянуть, что термины Показать модель и Модель домена разные. Модель домена - это термин, описывающий все сервисы, бизнес-логику и DAL, скрытые от контроллера с некоторым фасадом. Модель View - это класс, который инкапсулирует данные, необходимые для просмотра. Он может совместно использоваться моделью домена в простых случаях. Почему два класса?

Вот аналогичные фрагменты кода ASP.NET MVC и WebForms, выполняющие одни и те же вещи: 1) получение данных 2) обработка данных. В обоих случаях я предполагаю, что IDomainModel вводится.

MVC:

public class SomeController : Controller
{
    // injected
    public IDomainModel Domain { get; set; }

    public ViewResult Edit()
    {
        var record = Domain.GetRecord(1);
        var dictionary = Domain.GetSomeDictionary();
        var model = new SomeViewModel(record, dictionary);

        return View(model);
    }

    [HttpPost]
    public ActionResult Edit(SomeViewModel model)
    {
        if (ModelState.IsValid)
            // save
            return RedirectToAction("Result");
        else
            return View(model);
    }
}

WebForms:

public partial class SomePage : System.Web.UI.Page
{
    // injected
    public IDomainModel Domain { get; set; }

    protected void Page_Load(object sender, EventArgs e)
    {
        var record = Domain.GetRecord(1);
        var dictionary = Domain.GetSomeDictionary();

        RecordId.Text = record.Id.ToString();
        RecordName.Text = record.Name;
        RecordDescription.Text = record.Description;

        DicValue.DataSource = dictionary;
        DicValue.DataValueField = "Id";
        DicValue.DataTextField = "Value";
        DicValue.SelectedValue = record.DictionaryEntryId.ToString();
        DicValue.DataBind();
    }

    protected void btnSave_Click(object sender, EventArgs e)
    {
        var record = new RecordModel
        {
            Id = Int32.Parse(this.RecordId.Text),
            Name = this.RecordName.Text,
            Description = this.RecordDescription.Text,
            DictionaryEntryId = Int32.Parse(this.DicValue.Text)
        };
        // save
    }
}

Тестирование MVC-контроллера Edit GET невероятно прост:

[TestMethod]
public void EditGetTest()
{
    SomeController target = new SomeController();

    var record = new RecordModel { Id = 1, Name = "name1", Description = "desc1", DictionaryEntryId = 1 };
    var dictionary = new List<SomeDictionaryEntry>
    {
        new SomeDictionaryEntry { Id = 1, Value = "test" }
    };

    target.Domain = new SimpleMVCApp.Models.Fakes.StubIDomainModel()
    {
        GetRecordInt32 = (id) => { return record; },
        GetSomeDictionary = () => { return dictionary; }
    };

    var result = target.Edit();

    var actualModel = (SomeViewModel)result.Model;
    Assert.AreEqual(1, actualModel.Id);
    Assert.AreEqual("name1", actualModel.Name);
    Assert.AreEqual("desc1", actualModel.Description);
    Assert.AreEqual(1, actualModel.DictionaryEntryId);
}

Чтобы протестировать события WebForms, нам нужно сделать много изменений и допущений: нам нужно сделать методы общедоступными, нам нужно инициализировать форму и ее элементы управления. Это приводит к тяжелому анализу, который невозможно для 3) TDD.

2. Включить полный контроль над отображаемым HTML

Я думаю, что это утверждение немного преувеличено. Только HTML может полностью контролировать отображаемый HTML. Что касается HtmlHelpers, DisplayTemplates и EditorTemplates, хотя команда сделала значительные улучшения в 6 версиях фреймворка, все равно иногда раздражает преобразование дополнительныхViewData в атрибуты html.
Например, чтобы передать некоторые html-атрибуты на вход, вы не можете использовать @Html.EditorFor, вам нужно будет использовать @Html.TextBoxFor.
В то же время в ASP.NET вы можете указать любые атрибуты для любых элементов, и они просто будут отображаться.

MVC:

Неправильно:

@Html.EditorFor(m => m.Name, new { MySuperCustomAttribute = "Hello" })

Правильно:

@Html.TextBoxFor(m => m.Name, new { MySuperCustomAttribute = "Hello" })

ASP.NET:

<asp:TextBox runat="server" ID="RecordName" MySuperCustomAttribute="hello"></asp:TextBox>

3. Включить тестовое развитие (TDD)

Я думаю, что это утверждение относится к тестированию Controller vs Code-Behind. Я рассмотрел это в 1.

4. Нет событий ViewState и PostBack

ViewBag и ViewData являются слабоспециализированными средствами для передачи данных между контроллером и представлениями. Они отображаются как элементы, ничего похожего на ViewState. Например, в моем представлении я инициализируется ViewBag.Title = "EditView";, который позволяет мне использовать эту строку на странице макета: <title>@ViewBag.Title - My ASP.NET MVC Application</title>. На странице это выглядит так: <title>EditView - My ASP.NET MVC Application</title>

Что касается TempData, Session и Application, они хранятся на стороне сервера. Это не отображается на странице.

5. Легкая интеграция с JQuery

Я не вижу, как упрощение интеграции с JQuery для MVC. Вот как мы интегрируем JQuery в WebForms:

<script src="Scripts/jquery-1.8.2.min.js"></script>
<script>
$(document).ready(function () {
    $('#DicValue').change(function () {
        $('#ChosenValue').text($('#DicValue option:selected').val());
    });
});
</script>

И вот почти такой же фрагмент для ASP.NET MVC:

@section scripts{
<script src="~/Scripts/jquery-1.8.2.min.js"></script>
<script>
$(document).ready(function () {
    $('#DictionaryEntryId').change(function () {
        $('#ChosenValue').text($('#DictionaryEntryId option:selected').val());
    });
});
</script>
}

Здесь есть еще один момент, чтобы упомянуть о JQuery: поскольку ASP.NET MVC является довольно мнимой структурой, он становится несколько ограничивающим для широкого использования JS. Он был первоначально разработан для разработки на основе шаблонов Scaffold, и с ним лучше всего. JQuery хорош для запросов ajax и для некоторой незначительной логики в ASP.NET MVC, но когда вы начнете широко использовать его, вы получите два контроллера для каждого представления: С# один и JS. Привет, Unit Testing! Также JQuery (UI) очень хорош с его богатым набором элементов управления пользовательского интерфейса.

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

Ничего себе, это был длинный ответ. Надеюсь, это поможет.

Ответ 2

Ok.

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

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

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

Позволяет идти по точкам.

Разделение проблем (SoC): MVC обеспечивают чистое, организованное и гранулированное решение на разных уровнях, например. Есть несколько вспомогательных классов, которые перехватывают и помогают в поздних привязках, вы можете имитировать контроллер с помощью различных плагинов. Легко разрабатывать классы помощников.

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

Включить тестовое развитие (TDD): С дисциплиной вы можете сделать это и в архитектуре

Нет событий ViewState и PostBack: Viewstate добавляет дополнительную нагрузку на страницу и в веб-формы, когда вы видите источник страницы с множеством элементов управления, сеткой и т.д., Вы увидите огромное пространство просмотра. Если нет жизни в представлении, это просто. ViewData находится на стороне клиента, тогда как другие находятся на стороне сервера.

Легкая интеграция с JQuery: Действительно, MVC3, 4 имеют превосходную поддержку JQuery. Есть много предопределенных JQueries, которые уже введены в шаблоны.

Помимо вышеописанных пунктов, некоторые дополнительные точки Пакетирование Обновленные и модернизированные шаблоны проектов по умолчанию Улучшенная поддержка мобильных приложений Быстрое развитие Повторное использование кода Наименьшее сцепление в слоях Хорошая поддержка Ajax

Посмотрите на несколько ссылок

http://www.codeproject.com/Articles/683730/New-Features-in-ASP-NET-MVC http://www.asp.net/mvc/tutorials/hands-on-labs/whats-new-in-aspnet-mvc-4

Разница между ASP.NET MVC 3 и 4?

Ответ 3

Вот официальный ответ Microsoft на этот вопрос: http://www.asp.net/get-started/websites

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

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

Ответ 4

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

Преимущества веб-приложения на основе MVC

Структура ASP.NET MVC предлагает следующие преимущества:

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

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

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

Он обеспечивает лучшую поддержку тестовой разработки (TDD).

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

Преимущества веб-приложения на основе веб-форм

Основанная на Web Forms инфраструктура предлагает следующие преимущества:

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

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

Он использует состояние просмотра на серверных формах, что облегчает управление информацией состояния.

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

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

Источник http://msdn.microsoft.com/en-us/library/dd381412 (v = vs .108).aspx