ASP.Net Web API架构选择

以下是情况的示意图：

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

> Webserver：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应用程序.

解决方法

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

这里的要点是每一层都应该提供一个真正的价值.仅仅为了分层的层是不好的.

所以历史上我们在做：

> DB =>提供数据
>中间层=>提供服务(应用于数据的业务逻辑)
> ASP.NET网站(表示层)=>提供渲染视图

现在,通过SPA和新的支持js的富客户端,可以在客户端上呈现视图.因此,服务的表示层现在是冗余的(尽管低端客户端可能仍然需要).

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

> DB =>提供数据
>服务层=>提供服务

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

>数据访问
>业务
> Web API向支持js的客户端,其他客户端(Silverlight,Air等)以及其他服务和系统(联合,mash-up,B2B,…)提供数据(以及向低端客户端提供呈现视图的MVC)

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