Надеюсь, вы знаете разницу между HTML, Ajax и Asp.net, поэтому я не буду утомлять вас этим и просто укажу на ответ. Я добавлю некоторые знания Javascript в эту же сумку.
HTML + Ajax
Каждое Ajax-приложение на самом деле является приложением HTML + Ajax, поскольку оно использует HTML + CSS для отображения визуальных данных и Ajax для асинхронной связи с сервером. Последняя часть server так же важна, если вы намереваетесь написать приложение. Так что в основном HTML + Ajax - это просто определение вашего приложения на стороне клиента.
Asp.Net + Ajax
Теперь это означает, что вы будете использовать инфраструктуру Asp.net на стороне сервера (в отличие от PHP, J2EE или чего-то еще). Но будьте осторожны, так как у нас есть две серверные платформы Asp.net:
Asp.net WebForms - это похоже на разработку приложений для рабочего стола Windows, потому что большая часть обработки основана на событиях (нажатие кнопки, изменение текстового поля и т. Д.). Это и хорошо, и плохо. Хорошая часть заключается в том, что довольно легко написать веб-приложение с абстрагированным протоколом HTTP, но плохая часть в том, что для абстрагирования коммуникационного протокола и функциональности клиента необходимо выполнить некоторую конвейерную обработку с дополнительными переменные (которые могут стать огромными), о которых вы должны знать, потому что настольные приложения не сохраняют состояние, с другой стороны - протокол HTTP, и это смягчается уровнем абстракции WebForms.
Приложения WebForms обычно заканчиваются раздутым деревом элементов HTML DOM, большим количеством обратных ссылок на страницы и полной перезагрузкой страницы (мерцание страницы) и иногда странным поведением, которое невозможно объяснить, если вы не знаете, как оно работает в фоновом режиме. .
WebForms также предоставляют огромный набор полнофункциональных веб-элементов управления на стороне сервера, которые представлены на сервере как единый элемент управления, но отображаются на клиенте как сложный HTML-код (т. Е. Элемент управления Calendar). Они обычно инкапсулируют большую часть своей модели событий и функциональности и часто также осведомлены о данных. Это хорошо, потому что разработка быстрее, но также и плохо, когда вам нужно сделать что-то, что не совсем соответствует поведению элемента управления по умолчанию. Всякий раз, когда вы отклоняетесь от этого значения по умолчанию, вы скоро будете писать гораздо больше кода, и знание этих элементов управления станет очень актуальным. Это может также привести к написанию всех видов сантехники и хакерского кода.
Asp.net MVC - это более новая структура, которая не абстрагируется от протокола HTTP и по своей природе не имеет состояния и очень хорошо подходит для HTTP (фактически она была написана с использованием протокола в ум все время). Хорошая часть заключается в том, что вы полностью контролируете свой HTML-код, а также более или менее выполняете страницу. Ничто такое большое, как состояние + HTTP, не абстрагируется, и оно использует очень упрощенную модель выполнения, которая также очень расширяема. плохая часть - это , что вы можете в конечном итоге написать больше HTML (нет такого понятия, как серверные элементы управления), что займет больше времени, но я считаю, что в долгосрочной перспективе гораздо проще поддерживать и создавать код он более стабилен и приложение быстрее, потому что все это гораздо более модульно и упрощенно.
Asp.net MVC не поддерживает серверные элементы управления (хотя вы можете использовать серверные элементы управления WebForm, хотя я настоятельно рекомендую не делать этого), но он поддерживает методы расширения Html, которые могут обеспечить более сложную визуализацию HTML в краткой линия. Проекты с открытым исходным кодом, такие как MVCContrib , предоставляют некоторые более богатые расширения HTML, которые вы можете использовать. Я ими не пользуюсь, но некоторые используют.
Давайте тогда добавим немного Ajax
Когда мы думаем о двух инфраструктурах на стороне сервера, WebForms предоставляют своего рода UpdatePanel элемент управления на стороне сервера, который был быстрым обходным путем для разработчиков Asp.net WebForms, чтобы абстрагироваться от уровня HTTP (еще раз), поэтому все еще работает как раньше. Легко создавать Ajax-подобные приложения с использованием этого серверного элемента управления, но способ, которым он работает, означает, что он будет намного медленнее, не будет хорошо масштабироваться на сервере и, в общем, не такая уж и великая идея. Если вы спросите меня, это было быстрое решение Microsoft для разработчиков, чтобы дать им Ajax без особого обучения. Примите это, и вы сможете похвастаться своим приложением на Ajax.
Asp.net MVC, с другой стороны, очень дружественный к Ajax из-за его упрощенной модели выполнения и потому, что он очень хорошо подходит для протокола HTTP. Использование Ajax обычно выполняется сторонними клиентскими библиотеками (по умолчанию предпочтительным является jQuery). Библиотеки обычно используются, поэтому вам не нужно иметь дело с различными возможностями браузера. Библиотека делает это единообразным среди клиентов. Но вы можете использовать любую библиотеку, которую вы предпочитаете (это хорошо, чтобы не ограничивать вас в любом случае) Если бы вы писали динамические веб-сайты, вы, вероятно, выбрали бы jQuery. Но если вы разрабатываете бизнес-ориентированное веб-приложение для интрасети, вам, вероятно, придётся использовать что-то вроде ExtJS , потому что оно предоставляет очень богатые клиентские элементы управления и знакомый опыт настольных приложений из богатых приложений. Очень сильный кандидат для таких приложений.
Какой тогда вердикт?
Если вы еще не занимались разработкой на Asp.net (но знаете это в некоторой степени) и хотели бы использовать Ajax, я предлагаю вам сделать решающий шаг и начать с Asp.net MVC + jQuery. Это будет намного легче разрабатывать и намного проще учиться и поддерживать. Это также означает, что вы будете писать сценарии Javascript для выполнения на стороне клиента.
Но если вы не очень склонны к Ajax и хорошо знакомы с веб-формами Asp.net, то я предлагаю вам сделать это с помощью веб-форм Asp.net. Но имейте в виду, что у вас могут быть некоторые будущие требования. Тогда вам придется уменьшить их ограничения на использование веб-форм Asp.net.
В конце концов, более проблематичным будет правильный выбор серверных инструментов и технологий. Что вы будете использовать для DAL и BLL и как вы будете структурировать свое приложение.
Что еще можно сделать, используя стек технологий Microsoft?
Несколько лет назад я работал над веб-приложением LoB, использующим этот стек технологий: веб-формы Asp.net (в основном для локализации и обработки главной страницы), ExtJS 2, Ajax и WCF с JSON. Веб-формы Asp.net обслуживали базовую загрузку страницы, затем большая часть пользовательского интерфейса была сгенерирована на клиенте с использованием ExtJS, и все вызовы Ajax обрабатывались службой WCF. Буду ли я делать то же самое сегодня? Нет. Я бы просто использовал Asp.net MVC, который не был доступен в то время, и вообще избавился бы от WCF и Webforms.