Не полный ответ, но одно большое беспокойство является тестируемостью Форм ASP.NET или отсутствием этого. Тестирование логики UI того, что отображено и как. С Формами ASP.NET Вас оставляют просто codebehind.

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

Но, тестируемость является действительно большим плюс для тестирования Вашего кода. Такой, поскольку 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"]);
    }
}

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

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

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

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

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

MVC потребует, чтобы у Вас было лучшее знание основных арендаторов веб-разработки (ДОБЕРИТЕСЬ, POST, ЗАПРОС, HTML, CSS, JavaScript), результат будет намного лучше. Посмотрите мой график того, как я думаю работы MVC :-)

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

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

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

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

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

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

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

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

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

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

Это будет идти со временем. Едва ли долгое время.:)

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

Также при выполнении веб-сайтов в HTML и CSS в течение долгого времени Mvc намного лучше, поскольку Вы имеете полный контроль над своим выводом HTML.

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

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

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

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

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

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