Веб-формы ASP.NET + Ajax ASP.NET по сравнению с ASP.NET MVC и свобода платформы Ajax

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

Я согласен, что asp.net ajax UpdatePanels не идеальное решение.

Мы избегали их использования и вместо этого использовали библиотеки на стороне клиента для связи с сервером. Мне нравится то, что я видел на PDC о возможностях asp.net ajax 4.0 с декларативными компонентами и шаблонизацией на стороне клиента - очень приятно! Комбинация JQuery с существующими библиотеками дает довольно много - и я поставил под сомнение использование JQuery исключительно вместо этого, учитывая, что он занимает гораздо меньше места и обладает способностью делать то же самое, что и клиентская библиотека asp.net ajax.

Что касается стека серверов - я еще не использовал MVC, но мы добились успеха, используя домашний подход MVP с использованием веб-форм.

Я использовал winforms asp.net с ajax.net, а также прототипом/расширением/jQuery. Я предполагаю, что что-то для рассмотрения является целью сайта.. MVC является популярным шаблоном. Я ничего не могу сказать против ASP MVC, потому что у меня не было шанса использовать его, но я хочу удостовериться, что Вы знаете, что не ограничены просто ajax.net при выборе веб-форм.

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

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

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

, Если бы Вы запускаете новый проект теперь, я рекомендовал бы придерживаться веб-форм asp.net и использовал бы созданный в asp.net ajax, инструментарии и jQuery по мере необходимости. asp.net ajax реализация не может быть абсолютным лучшим, или наиболее эффективным внедрением, но если Вы не получаете миллион uniques в день 1, или Ваш сервер является коммодором vic 20, хит производительности не будет этим примечательным.

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

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

Веб-формы с ASP.NET Ajax - это рай . Интеграция между двумя просто удивительна, и с ней приятно работать.

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

Но я все еще хотел бы добавить немного jQuery в микс для обхода dom и добавления анимации, я просто хотел бы использовать asp.net ajax для интеграции с серверной стороной.

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

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

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

На передней стороне Ajax, я сказал бы попытку найти библиотеки (коммерческий или иначе), которые делают то, что Вы ищете. Основы (Сетки, деревья, текстовые поля автоматического заполнения, и т.д.) были сделаны до смерти. Не Перестраивайте Колесо.

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

Не позволяйте людям обманывать вас, думая, что это четкий выбор. Вы можете получить лучшее из обоих миров. Мой подход заключается в создании проекта 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, действительно упрощает вещи.

Я люблю веб-формы, но Ajax ASP.NET является грудой дерьма.

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

Heh, downvoted...

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

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

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

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

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

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

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

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

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