4

以下是情况的示意图:

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

  • 网络服务器:IIS / ASP.net 4.0 (WebForms & MVC)
  • 中间件服务器:WCF Services
  • 数据库服务器:甲骨文

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

4

1 回答 1

6

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

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

所以从历史上看,我们正在做:

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

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

我对典型的非大数据场景的建议是2 个物理层

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

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

  1. 数据访问
  2. 商业
  3. Web API 向支持 js 的客户端、其他客户端(Silverlight、Air 等)和其他服务和系统(联合、混搭、B2B 等)提供数据(和 MVC 向低端客户端提供渲染视图)

而且我相信支持 js 的富客户端。

于 2012-06-01T11:17:20.100 回答