architecture - ASP.Net Web API 架构选择

Question

以下是情况的示意图:

WEBSERVER <----> 中间件服务器 <----> 数据库

网络服务器:IIS/ASP.net 4.0 (WebForms & MVC)

中间件服务器:WCF Services

数据库服务器:甲骨文

Web 服务器与 Oracle 数据库在物理上是分开的。

我们想做的是在 Web 应用程序的前端使用 ASP.Net Web API 来将数据的快速绑定(bind)集成到使用 JQuery/KnockoutJS 的新单页应用程序中。因此，我们需要来自数据库中数据的 JSON API 才能使用 JQuery 进行访问。

我们想使用 PetaPoco 与数据库对话。

但是，WEB API 项目必须在中间件服务器上运行才能从数据库中获取数据。但是当然，我们永远无法在前端使用 JQuery 访问 WEB API。

我正在考虑在 Web 服务器上设置一个 WEB API，它使用不同的技术连接到中间件服务器，可能就像我们现在所做的那样，使用普通的旧 WCF。
然而，这似乎太过分了。

有人对如何改进此架构有一些见解吗？我确定有人在类似的环境中使用 WEB API 设置了 SPA 应用程序。

Answer 1

在过去的十年中，物理分层一直被认为是一件好事。 N层很好。

这里的重点是每一层都应该提供一个 实际值 。仅仅为了分层而分层是不好的。

所以从历史上看，我们正在做:

DB => 提供数据

中间层 => 提供服务(应用于数据的业务逻辑)

ASP.NET 网站(表示层)=> 提供渲染 View

现在有了 SPA 和新的启用 js 的富客户端， View 在客户端上呈现。因此，服务的表示层现在是多余的(尽管低端客户端可能仍然需要)。

我对典型的非大数据场景的建议是 2 个物理层 :

DB => 提供数据

服务层 => 提供服务

在服务层中，我们将有 3 个逻辑层 :

数据访问

业务

Web API 向支持 js 的客户端、其他客户端(Silverlight、Air 等)和其他服务和系统(联合、混搭、B2B ......)提供数据(和 MVC 为低端客户端提供渲染 View )

而且我相信支持 js 的富客户端。