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 回答