Блог

Я собираюсь создать персональное веб-приложение (например, систему для управления личной информацией)

Я решил использовать веб-сервис на стороне сервера. Но сбивает с толку выбор технологии при разработке клиента.

Кто-нибудь может сказать мне, в чем разница между этими:

1. используйте html / ajax
2. использовать asp.net/ajax

Я надеюсь, вы знаете разницу между HTML, Ajax и Asp.net поэтому я не буду утомлять вас этим и просто перейду к ответу. Я также добавлю некоторые знания Javascript в этот же пакет.

HTML Ajax

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

Asp.Net Ajax

Теперь это означает, что вы будете использовать Asp.net фреймворк на стороне сервера (в отличие от PHP, J2EE или чего-то еще). Но будьте осторожны, поскольку у нас есть два серверных Asp.net фреймворки:

1. Asp.net WebForms — это похоже на разработку приложений для настольных компьютеров Windows, потому что большая часть обработки каким-то образом основана на событиях (нажатие кнопки, изменение текстового поля и т.д.). Это как хорошо, так и плохо. Хорошая часть заключается в том, что довольно легко написать веб-приложение с абстрагированным протоколом HTTP, но плохая часть в том, что для абстрагирования протокола связи и клиентской функциональности ему приходится выполнять некоторую конвейерную обработку с дополнительными переменными (которые могут стать огромными), о которых вы должны знать, потому что настольные приложения не являются апатридными, протокол HTTP, с другой стороны, является, и это смягчается уровнем абстракции WebForms.

   Приложения WebForms обычно заканчиваются раздутым деревом элементов HTML DOM, множеством обратных отправлений страницы и полной перезагрузкой страницы (также известной как мерцание страницы), а иногда и странным поведением, которое невозможно объяснить, если вы не знаете, как это работает в фоновом режиме.

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

2. Asp.net MVC — это более новая платформа, которая не абстрагируется от протокола HTTP и по своей природе не имеет состояния и очень хорошо подходит для HTTP (на самом деле она была написана с учетом протокола все время). Хорошая часть заключается в том, что вы полностью контролируете свой HTML и более или менее также выполнение страницы. Ничто настолько большое, как state 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 Тогда ограничения WebForms.

В конечном итоге более проблематичным будет правильный выбор ваших серверных инструментов и технологий. Что вы будете использовать для DAL и BLL и как вы будете структурировать свое приложение.

Что еще можно сделать, используя Microsoft stack of technologies?

Несколько лет назад я работал над большим веб-приложением, которое использовало этот набор технологий: Asp.net Веб-формы (в основном для локализации и обработки главной страницы), ExtJS 2, Ajax и WCF с использованием JSON. Asp.net Веб-формы обслуживали базовую загрузку страницы, затем большая часть пользовательского интерфейса была сгенерирована на клиенте с использованием ExtJS, а все вызовы Ajax обрабатывались службой WCF. Сделал бы я то же самое сегодня? Нет. Я бы просто использовал Asp.net MVC, который в то время был недоступен, и полностью избавиться от WCF и Webforms.

ASP.Net — это платформа веб-приложения, которая использует HTML наряду с функциями на стороне сервера. HTML — это язык разметки, простой и понятный. ASP.Net использует этот фреймворк, чтобы помочь вам создавать веб-приложения.

С точки зрения вашего проекта, если ваша система поддерживает связь с пользователем (принимает информацию и сохраняет ее и т.д.), Тогда вам нужна технология на стороне сервера. ASP.Net решил бы это. Или вы могли бы использовать PHP и MySQL.