ASP.NET Web API架构选择

Question

以下是情况的概述：

WEBSERVER <----> MIDDLEWARE SERVER <----> 数据库

Web服务器：IIS / ASP.net 4.0（WebForms和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应用程序。

- Rody

Answer 1

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

关键在于每一层都应该提供真正的价值。单纯为了分层而分层是不好的。

所以历史上我们做的是：

1. 数据库 => 提供数据
2. 中间层 => 提供服务（将业务逻辑应用于数据）
3. ASP.NET网站（表现层） => 提供呈现视图

现在随着SPA和新的js-enabled rich clients，视图在客户端上呈现。因此，服务的表现层现在是多余的（尽管对于低端客户端可能仍然需要）。

对于一个典型的非BigData场景，我的建议是2个物理层：

1. 数据库 => 提供数据
2. 服务层 => 提供服务

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

1. 数据访问
2. 业务
3. Web API向js-enabled clients、其他客户端（Silverlight、Air等）、其他服务和系统（联邦、混搭、B2B等）提供数据（以及MVC向低端客户端提供呈现视图）

而我相信js-enabled rich client。

- Aliostad

---

顺便提一下：Twitter 将渲染从客户端移回到服务器端。 - Zote

http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/ - Zote