Является ли [HTML5 + jQuery] (без ASP.NET) + WCF правильным решением для веб-приложения уровня предприятия? - PullRequest
13 голосов
/ 27 января 2012

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

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

Нет .ASPX, нет .cshtml / .vbhtml, только чистые файлы .HTML, чтобы избежать логики и рендеринга на стороне сервера. Это идея, которую некоторые предлагают, и она становитсяболее привлекательным с HTML5 и его функциями.Способность ориентироваться на большее количество устройств, имея полный контроль над HTML, также является движущим фактором.

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

Вопрос сводится к следующему:

  1. Является ли это действительным беспокойством, и если да, то каким видом сантехники мы можем в итоге заниматься?
  2. Что именночто мы можем потерять, отбросив всю инфраструктуру ASP.NET в сторону (со стороны веб-приложения) и просто полагаясь на прямую связь с нашим сервисом WCF с чистых страниц HTML?

Примечание: я использовал термин«корпоративный уровень», чтобы подчеркнуть, что это не простое веб-приложение с несколькими страницами, где окончательное решение базовой архитектуры не имеет значения, мы говорим о приложении с большой задницей:)

Редактировать: Чтобы быть еще яснее, основные области, которые вызывают у нас интерес при таком подходе:

  • Аутентификация и авторизация -> MVC обрабатывает это очень простым способом с помощью атрибутов (например, AuthorizeAttribute ), однако этот «статический» подход означает, что WCF придется обрабатывать токены, шифровать / дешифровать их и решать, какиеo получает возможность делать все самостоятельно, сохраняя всю эту информацию на каждом звонке. Это единственное решение?

  • Разделение концерна -> MVC четко это делает, и, может быть, я очень хорошо добавлю.Однако этот подход вынуждает вас явно писать в своем HTML, какой вызов функции WCF необходим.Таким образом, не только ваш уровень представления обрабатывает то, что нужно рисовать, он также включает в себя логику того, что вызывать для получения своих данных, и как распределять их на странице.Это может быть не таким уж большим делом, но, напротив, ViewBag в MVC дает вам возможность иметь URL-адреса ваших служб WCF в качестве динамического свойства, то есть логика теперь является частью вашего контроллера, а не вашей HTML-страницы.Изменение этой логики освобождает от необходимости просматривать страницы HTML в целом.

  • Binding & Validation -> Я поместил эти два в одну корзину, потому что в конечном итоге однаждыСлужба WCF отвечает объектом JSON, содержащим всю информацию, необходимую моей странице для функционирования (включая правила проверки), которые кто-то должен будет привязать к этим элементам управления.

Надеюсь, что идея достаточно ясна, и спасибо заранее.

Ответы [ 2 ]

3 голосов
/ 27 января 2012

Вы не «выбросили всю абстракцию на стороне сервера», вы разделяете функциональность не так, как стандартное веб-приложение. Абстракция на стороне сервера теперь поступает от службы WCF, которая предоставляет данные на уровне представления

Вам потребуется использовать API веб-стиля, чтобы вернуть JSON, чтобы его было легко использовать - и я бы предложил использовать новый Web API для этого, поскольку он дает вам точный контроль над HTTP-взаимодействием, которое было несколько скрыто в предыдущих Реализация REST в WCF

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

Вероятно, единственным недостатком является то, что для каждой страницы будет по крайней мере два обхода - один для получения HTML + JS, а другой для JS для получения данных - в традиционном веб-приложении есть только один прием в оба конца. добиться того же, что загружаются данные серверной стороны при рендеринге страницы в первую очередь

2 голосов
/ 27 января 2012

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

dislaimer : Я работаю в Telerik, хотя напрямую не занимаюсь этим продуктом, и мы также используем его внутри компании.Я не из отдела продаж и не из отдела разработки - я просто думаю, что это именно то, что вам нужно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...