ASP.Net网页API体系结构选择

Question

以下是的情况的示意性概览：

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

• 网络服务器：IIS/ASP.net 4.0（Web窗体& MVC）
• 中间件服务器：WCF服务
• 数据库服务器：甲骨文

网络服务器与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 =>提供（适用于数据业务逻辑）数据
2. 中间层=>提供服务
3. ASP.NET网站（表示层）=>提供SPA和新启用的JS-富客户端渲染视图

现在，视图显示在客户端上。因此，服务的表示层现在是多余的（虽然低端客户端可能仍然需要）。

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

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

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

1. 数据访问
2. 业务
3. 的Web API提供的数据（和MVC提供渲染以低端客户端），以支持JS的客户，其他客户端（Silverlight的，空气等），以及其他服务和系统（联合会，mash-up，B2B，...）

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