ASP.Net Web API架构选择

Question

以下是情况的示意图:

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

Answer 1

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

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

所以历史上我们在做:

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

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

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

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

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

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

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