ASP.Net Web API архитектуры выбор

Question

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

< WEBSERVER ----> MIDDLEWARE SERVER < ----> База данных

• Вебсервер: IIS/ASP.net 4.0 (WebForms & MVC)
• Middleware сервер: WCF Services
• сервер базы данных: Oracle

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

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

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

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

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

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

Answer 1

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

Дело в том, что каждый слой должен обеспечивать реальную стоимость . Слой только для наслаивания не очень хорош.

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

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

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

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

1. DB => предоставляют данные
2. Service слой => предоставляют услуги

В сервисный слой будет иметь 3 логических уровня:

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

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