ASP.NET веб-форм + ASP.NET Ajax против свободы ASP.NET MVC и Ajax Framework

Question

Если бы у вас был выбор, какой путь вы бы выбрали?

ASP.NET Webforms + ASP.NET AJAX

или

ASP.NET MVC + JavaScript Framework по вашему выбору

Существуют ли какие-либо ограничения, которые ASP.NET Webforms / ASP.NET AJAX имеет по отношению к MVC?

Answer 1

Я сделал оба в последнее время, я бы взял MVC девять раз из десяти.

• Мне очень не нравится реализация элементов управления ajax asp.net, я столкнулся с множеством проблем с синхронизацией, событиями и отладкой проблем обратной передачи. Я многому научился у http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
• В проекте asp.net мы использовали шаблон MVP http://www.codeplex.com/aspnetmvp,, и шаблон работал отлично. Однако мы получили много кода в представлении, потому что мы напрямую взаимодействовали с элементами управления на стороне сервера (т.е. много манипуляций с gridview). Этот код практически не тестируется в рамках модульных тестов. Мы должны были быть более усердными в том, чтобы не показывать код, но в некоторых случаях это было проще и менее грязно.

Единственный раз, когда я бы выбрал использование форм asp.net, это использование элемента управления gridview. Мы используем jquery для нашей платформы javascript с MVC и еще не нашли очень хорошего вида сетки, подобного элементу управления. У нас есть что-то функциональное, но мы потратили много времени на изучение, настройку и отладку по сравнению с использованием серверных элементов управления asp.net. Один из них теряет все приятные виджеты, которые Microsoft предоставляет из коробки, выполняя разработку форм не asp.net. Потеря этих виджетов освобождает и пугает одновременно при первом запуске.

В конце дня я рад, что мы занимаемся разработкой MVC. Моя команда и я изучили новый фреймворк (раньше мы были только разработчиками asp.net) и испачкали руки html и javascript. Это навыки, которые мы можем использовать в других проектах или на других языках, если нам это понадобится.

Answer 2

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

public partial class SamplePage : System.Web.Mvc.ViewPage
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

Если вы ограничиваетесь одним тегом формы (с runat = "server") в коде впереди, то у вас есть полный код для доступа к вашим стандартным серверным элементам управления asp.net. Это означает, что вы получаете полный контроль над представлением на стороне сервера (например, с помощью привязки данных и повторителей) без необходимости выполнять это старое кодирование в стиле ASP.

    protected void Page_Load(object sender, EventArgs e)
    {
        IObjectDefinition instance = (IObjectDefinition)ViewData["definition"];
        _objectName.Text = instance.DisplayName;//textbox or label

        DataTable itemVals = new DataTable();
        itemVals .Columns.Add("itemName");
        itemVals .Columns.Add("itemValue");            


        IDictionary<string, string> items = (IDictionary<string, string>)ViewData["items"];
        foreach (KeyValuePair<string, string> datum in items)
        {
            conditions.Rows.Add(new object[] { datum.Key, datum.Value});
        }

        _itemList.DataSource = itemVals;//repeater
        _itemList.DataBind();
    }

Публикация для любого элемента управления отправляется не обратно на страницу, а на контроллер. Если вы не забываете использовать свойство name на своих серверных элементах управления, они попадают в коллекцию FormControls для доступа к переменным вашей страницы в соответствии со стандартом MVC.

Так что вы получаете?:

• полный контроль на стороне сервера для представления вашего кода перед вами - только теги HTML и asp.net для управления сервером
• полное разделение интересов - страница выполняет только презентацию, а также всю оркестровку и сортировка выполняется в контроллере (а не в стиле asp.net на странице)
• полная тестируемость MVC
• Нет сотки HTML-кода
• Вы можете отключить просмотр состояния и уменьшить количество страниц

Что вы теряете?

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

Да, а для AJAX - jQuery определенно. Выполнение запроса к методу контроллера, который возвращает JsonResult, действительно упрощает вещи.

Answer 3

Я люблю веб-формы, но ASP.NET AJAX - куча дерьма.

Я предпочитаю использовать WebForms + пользовательские HTTPHandlers для обработки серверной части любых вызовов AJAX.

Хех, понизился ...

ASP.NET AJAX - куча дерьма, потому что обратный вызов требует, чтобы весь класс страницы был восстановлен, вы не вызываете ни одного метода, вы каждый раз перестраиваете всю страницу на сервере.

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

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

Answer 4

Я вижу, что большинство ответов вышло до MVC 1.0. Поскольку сейчас мы находимся в версии 2.0 Preview, я подумал, что было бы неплохо вернуться к ней.

Я был разработчиком ASP.NET около пяти лет, прежде чем перешел в MVC в марте прошлого года. Я не пожалел об этом ни на секунду. Теперь я понимаю, что чем сильнее я становился в ASP.NET WebForms, тем труднее стало изучать другие технологии, такие как JavaScript и реализацию AJAX сторонних разработчиков. Microsoft использовала свой подход к разработке ASP.NET из своего подхода к разработке WinForms, который помог с кривой обучения, если вы шли из разработки WebForms, но это не очень хороший способ разработки веб-приложений, если вы понимаете различия между этими двумя подходами.

Последний проект, над которым я работаю, потребовал от меня изучения ASP.NET MVC, JavaScript, jQuery, CSS 2 и AJAX (не Microsoft). Всего через девять месяцев я чувствую себя гораздо лучше подготовленным к проектам веб-разработки, чем после пяти лет разработки ASP.NET. Реализация ASP.NET делает вещи намного сложнее поддерживать в долгосрочной перспективе. MVC делает все намного проще, потому что вы меньше зависите от ярлыков. Изучение фреймворка занимает некоторое время, но чем больше вы узнаете о фреймворке, тем меньше вы зависите от фреймворка и тем больше начинаете изучать и понимать установленные стандарты, такие как JavaScript и AJAX.

Для меня это - это четкий выбор. Я никогда не вернусь к ASP.NET. Если я не могу использовать ASP.NET MVC, я изучу Ruby или PHP. Я хочу, чтобы развитие и продвижение моих инструментов веб-разработки мотивировалось потребностями сообщества разработчиков, а не прибылью.

Answer 5

Если вам нужна панель обновления, я предлагаю вам использовать open source и lite MagicAjax или ComfortASP. Если вам нужна фреймворк, помогающий в разработке собственного ajax, я предлагаю jQuery.

Answer 6

Когда я проектирую сайт, одна из главных вещей, которые я предпочитаю, это принцип СУХОЙ. IMO ASP.NET MVC гораздо более сухой, чем веб-формы.

Я недавно перешел с веб-форм на MVC и надеюсь, мне больше не придется возвращаться!

Answer 7

ASP.NET MVC все еще находится в форме «предварительного просмотра», и поэтому я не буду рассматривать его, пока он не созреет. Вы можете легко свернуть свой собственный шаблон MVP без особых усилий.

На фронте Ajax я бы сказал, попытайтесь найти библиотеки (коммерческие или иные), которые будут делать то, что вы ищете. Основы (сетки, деревья, текстовые поля автозаполнения и т. Д.) Были сделаны до смерти. Не изобретай колесо.

Answer 8

чтобы ответить на вопрос @ ben, я использовал веб-формы ASP.Net для простого связывания данных и JQuery для всех транзакций Ajax. Честно говоря, я все еще не мог отпустить привязку данных из-за ее простоты. Viewstate почти бесполезен, поэтому я его отключаю. Вы можете использовать MVC, но имейте в виду, что на разработку функциональных возможностей, которые вы воспринимаете как само собой разумеющееся в формах, потребуется больше всего времени. Удачи, мужик!

Answer 9

Мой опыт был в программировании веб-приложений для серверов Apache на php и ruby. Когда я получил работу по сопровождению веб-приложения, написанного на asp.net (webforms), я погрузился в изучение микрософт-технологии создания веб-приложений. Я должен сказать, что я был полностью огорчен! Я думал, что WTF - весь этот мусор состояния представления отправляется назад вперед? Это даже необходимо?

И тогда я решил посмотреть на некоторые простые вещи с помощью ajax и jquery, которые привели меня к обновлению генерируемых панелей и clientID, а не к тому, что я установил в представлении. Что за трата моего времени! Почему я не могу иметь несколько форм на одной странице? Почему я не могу просто использовать обычные AJAX-звонки? Почему в моих представлениях логика сервера? Все это были вопросы, с которыми я уверен, что многие веб-программисты сталкиваются с веб-формами asp.net. Затем я обнаружил .NET MVC. Моя жизнь стала намного проще.

Я привык использовать фреймворки MVC, такие как Rails и CakePHP, для создания веб-приложений так, как они должны быть запрограммированы. С технологиями, действительно предназначенными для Интернета.

Мое предложение было бы таково: оставить веб-формы для людей, которые привыкли программировать приложения типа winforms, потому что он пытается абстрагировать тот факт, что вы программируете в Интернете. Если вы хотите иметь реальную свободу для разработки приложений для Интернета, которые действительно имеют смысл для веб-программистов, используйте .NET MVC или что-то подобное, что не будет вам мешать.

Вот мои два цента ...

Answer 10

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

Я также был ошеломлен, обнаружив ряд примеров, содержащих много логического кода в разметке. Правильно, операторы if и foreach в файлах aspx - ужасный шаг назад, imho. Я был очень рад оставить позади классический asp, но в текущей реализации шаблона asp.net mvc вы вернулись к коду в своей разметке, необходимости использовать помощников повсюду и отсутствию практически любых используемых серверных элементов управления.

Если вы начинаете новый проект сейчас, я бы порекомендовал придерживаться веб-форм asp.net и использовать встроенный asp.net asp.net, инструментарий и jQuery по мере необходимости. Реализация aspax в asp.net может быть не самой лучшей или самой эффективной реализацией, но если вы не получите миллион уникальных приложений в первый день или ваш сервер не станет столь значительным, снижение производительности не будет таким заметным.

Это, конечно, зависит от размера вашего проекта. Если вы запускаете 5-летнее приложение уровня предприятия, которое ожидает миллионы просмотров страниц, UpdatePanel может и не сократить его, но если вы создаете средний сайт, создаете прототип или просто хотите быстро двигаться, asp.net Ajax прекрасно работает и имеет очень низкую кривую обучения.

И чтобы быть ясным, вся страница абсолютно не возвращается каждый раз, когда делается вызов ajax. / Only / содержимое панели, которую необходимо обновить, передается по сети. Любой http-монитор докажет эту точку зрения. Да, страница / жизненный цикл / выполняется, но, зная, что вы можете создавать довольно эффективные приложения asp.net ajax.