Является ли [HTML5 + jQuery] (без ASP.NET) + WCF допустимым решением для веб-приложения корпоративного уровня?
Чтобы получить некоторую перспективу, мы давно использовали веб-формы ASP.NET.
Мы также знаем о преимуществах MVC по сравнению с веб-формами, однако сейчас обсуждают альтернативный вариант, который заключается в том, чтобы обойти все эти уровни абстракции и просто перейти от чистой страницы .HTML к службе WCF.
Нет.ASPX, без .cshtml / .vbhtml, только чистые файлы .HTML, чтобы избежать логики и рендеринга на стороне сервера. Эта идея предлагается некоторыми и становится все более привлекательной с HTML5 и его функциями. Возможность настроить таргетинг на большее количество устройств за счет полного контроля над HTML также является движущим фактором.
Я знаю, что это возможно с технической точки зрения - особенно с jQuery, который значительно упрощает работу, - но меня беспокоит, что, отбрасывая всю абстракцию на стороне сервера (код программной части в веб-формах, контроллере и привязке представлений в MVC) мы в конечном итоге сделаем больше сантехники, о которой нам не нужно было беспокоиться ранее.
Вопрос сводится к следующему:
- Является ли это обоснованным беспокойством, и если да, то каким сантехническим оборудованием мы можем в конечном итоге заняться?
- Что именно мы можем потерять, отбросив всю структуру ASP.NET в стороне (со стороны веб-приложения) и просто полагаясь на прямую связь с нашей службой WCF с чистых HTML-страниц?
NB: Я использовал термин «уровень предприятия», чтобы подчеркнуть, что это не простое веб-приложение с несколькими страницы, где окончательное решение базовой архитектуры не имеет значения, здесь мы говорим о большом приложении :)
Edit: Чтобы быть еще яснее, основные области, которые вызывают у нас озабоченность при таком подходе являются:
Аутентификация и авторизация -> MVC обрабатывает это очень простым способом с помощью атрибутов (например, AuthorizeAttribute ), этот «статический» подход, однако, означает, что WCF придется обрабатывать токены, шифровать / дешифровать их и решать, кто что будет делать сам, сохраняя при этом всю эту информацию на протяжении каждого вызова. Это единственное решение?
Разделение проблем -> MVC явно это делает, и делает это очень хорошо, могу я добавить. Однако этот подход вынуждает вас явно указать в HTML-коде, какой вызов функции WCF требуется. Таким образом, ваш уровень представления не только обрабатывает то, что рисовать, он также встроил в него логику того, что вызывать для получения данных и как распределять их на странице. Это может быть не так уж важно, но ViewBag в MVC, напротив, дает вам возможность иметь URL-адреса службы WCF в качестве динамического свойства, что означает, что логика теперь является частью вашего контроллера, а не вашей HTML-страницы. Изменение этой логики полностью избавляет от необходимости просматривать HTML-страницы.
Привязка и проверка -> Я положил эти два в одну корзину, потому что в конечном итоге, как только служба WCF ответит объектом JSON, содержащим всю информацию, необходимую для работы моей страницы (включая правила проверки), кто-то получит чтобы привязать его к этим незанятым элементам управления.
Надеюсь, идея достаточно ясна, и заранее спасибо.