Web API 在典型的 n 层架构中适合什么位置？答案

【问题标题】：Where does Web API fit in a typical n-tier architecture?Web API 在典型的 n 层架构中适合什么位置？
【发布时间】：2012-07-11 18:45:27
【问题描述】：

通常，当我为项目布局 n 层架构时，我有以下几层：

考虑到实际应用程序和外部客户端将使用 ASP.NET MVC 4 Web API，它在哪里适合？它是 service 层的一部分，还是使用 service 层并与 MVC 应用处于同一级别？

【问题讨论】：

【解决方案1】：

可能有两种方法：

您决定通过 HTTP 调用从 MVC 应用程序使用您的 Web API。在这种情况下，调用代码 (HttpClient) 位于您的数据层中。无论您是从数据库还是远程 Web 服务调用中获取数据，这都无关紧要。在这种情况下，由于 Web API 可能已经封装了大部分业务逻辑，因此您的服务层将非常薄，只是数据访问层的包装，如果不带来任何附加价值，甚至不存在。
由于 Web API 是用 .NET 编写的，因此您可以决定在 MVC 应用程序中直接引用包含此 API 服务层的程序集。在这种情况下，您的 Web API 应用程序的服务层将成为您的 MVC 应用程序的服务层。

【讨论】：

我认为第一种方法与我的想法一致。您提到 HttpClient 位于数据层中，这对我来说有点不清楚。 API 是否应该位于数据层之上的服务层之上，并且本质上充当 HTTP 包装器？我认为您所描述的是 API 应该替换两个层，而数据层是一个简单的 HttpClient 或某种查询 API 的 SDK。我的理解正确吗？
如果您采用第一种方法，请将 Web API 视为完全外部的东西。在这个 API 中，您可以再次拥有一个数据访问层、服务访问层和暴露的视图模型。但就您的 Web API 客户端而言，这并不重要。这是一个实现细节。
啊哈，我想你的最后一条评论让它点击了。我在想我可以在服务层之上构建 API，并且可能只是使用 RestSharp 为应用程序层和任何外部客户端公开一个 .NET SDK。谢谢你的回答！
新的 HttpClient 在许多方面提供了比 RestSharp 更好的方法。我们已经使用 HttpClient 成功构建了几个 REST API 客户端，并公开了 IObservable 以供 .NET 使用。将它与 IApiExplorer (blogs.msdn.com/b/yaohuang1/archive/2012/05/13/…) 结合起来，您就拥有了一个不错的机制来自动生成大部分所需的代码！

【解决方案2】：

有两种可能

中间层或中间件：这是 Web 服务和 WCF 服务通常工作的地方。使用 REST 比 SOAP 轻得多，因此这是事实上的用例。 Web 和 WCF 服务在客户端生成方面更好，但 Web API 将逐渐赶上。
表示层：这将为单页应用程序或任何使用数据并在客户端呈现的现代网站/应用程序提供数据。

【讨论】：