ASP.Net Web API架构选择

Question

以下是情况的示意图：

WEBSERVER＆lt; ----＆gt; MIDDLEWARE SERVER＆lt; ----＆gt;数据库

• 网络服务器：IIS / ASP.net 4.0（WebForms＆amp; MVC）
• 中间件服务器：WCF服务
• 数据库服务器：Oracle

Web服务器与Oracle数据库实际分离。

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

我们想使用PetaPoco与数据库交谈。

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

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

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

Answer 1

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

这里的要点是每一层都应提供实际值。仅仅为了分层的层次并不好。

历史上我们一直在做：

1. DB =＆gt;提供数据
2. 中间层=＆gt;提供服务（应用于数据的业务逻辑）
3. ASP.NET网站（表示层）=＆gt;提供渲染视图

现在，使用SPA和支持新js的富客户端，视图将在客户端上呈现。因此，服务的表示层现在是多余的（尽管低端客户可能仍然需要）。

我对典型非BigData 方案的建议是 2个物理层：

1. DB =＆gt;提供数据
2. 服务层=＆gt;提供服务

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

1. 数据访问
2. 商业
3. Web API向支持js的客户端，其他客户端（Silverlight，Air等）以及其他服务和系统（联合，mash-up，B2B，...）提供数据（以及向低端客户端提供渲染视图的MVC）。 ）

我相信一个支持js的富客户端。