Варианты архитектуры веб-API ASP.Net

Ниже приводится схематический обзор ситуации:

ВЕБ-СЕРВЕР ‹----> ПРОМЕЖУТОЧНЫЙ СЕРВЕР ‹----> База данных

  • Веб-сервер: IIS/ASP.net 4.0 (веб-формы и MVC)
  • Сервер промежуточного слоя: службы WCF
  • Сервер базы данных: Oracle

Веб-сервер физически отделен от базы данных Oracle.

Что мы хотели бы сделать, так это использовать веб-API ASP.Net во внешнем интерфейсе веб-приложений для интеграции быстрой привязки данных в новое одностраничное приложение с использованием JQuery/KnockoutJS. Поэтому нам понадобится JSON API из данных в базе данных для доступа с помощью JQuery.

Мы хотели бы использовать PetaPoco для общения с базой данных.

Однако проект WEB API должен работать на сервере промежуточного программного обеспечения, чтобы получить данные из базы данных. Но, конечно же, мы никогда не сможем получить доступ к WEB API, используя JQuery на внешнем интерфейсе.

Я думаю о настройке WEB API на веб-сервере, который подключается к серверу промежуточного программного обеспечения, используя другую технику, возможно, старый добрый WCF, как мы делаем сейчас. Однако это кажется таким излишним.

Кто-нибудь знает, как улучшить эту архитектуру? Я уверен, что кто-то настроил приложение SPA с использованием WEB API в аналогичной среде.


architecture single-page-application asp.net-web-api knockout.js petapoco
person Rody van Sambeek    schedule 01.06.2012    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Физические уровни считались хорошей вещью в течение последнего десятилетия. N-уровень был хорош.

Суть здесь в том, что каждый слой должен предоставлять реальное значение. Слой только ради слоя не годится.

Так исторически мы делали:

  1. БД => предоставить данные
  2. Средний уровень => предоставление услуг (бизнес-логика применяется к данным)
  3. Веб-сайт ASP.NET (уровень представления) => предоставляет визуализированные представления

Теперь, благодаря SPA и новым многофункциональным клиентам с поддержкой js, представление отображается на клиенте. Таким образом, уровень представления службы теперь является избыточным (хотя он все еще может быть необходим для недорогих клиентов).

Я рекомендую для типичного сценария не BigData 2 физических уровня:

  1. БД => предоставить данные
  2. Сервисный уровень => предоставлять услуги

На сервисном уровне у нас будет 3 логических уровня:

  1. Доступ к данным
  2. Бизнес
  3. Веб-API, предоставляющий данные (и MVC, предоставляющий визуализированное представление для низкоуровневых клиентов) клиентам с поддержкой js, другим клиентам (Silverlight, Air и т. д.) и другим службам и системам (федерация, mash-up, B2B,...)

И я верю в богатый клиент с поддержкой js.

person Aliostad    schedule 01.06.2012
comment
Примечание: твиттер переместил рендеринг с клиента обратно на сервер. - person Zote; 09.06.2012
comment
http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/ - person Zote; 11.06.2012