从 MVC 控制器调用 WEB API 服务是一种反模式吗？答案

【问题标题】：Is it an antipattern to call WEBAPI services from MVC Controllers?从 MVC 控制器调用 WEB API 服务是一种反模式吗？
【发布时间】：2012-07-15 05:13:23
【问题描述】：

如果决定使用 WebAPI 创建服务层以用于各种客户端。构建 Web 客户端的最佳方式是什么？

由于 WebAPI 是网络友好的，因此可以使用 javascript 直接从客户端使用它。但是我担心这会很快变得一团糟，而且 javascript 并不是最容易进行单元测试的技术。

另一种方法是使用 HttpClient 类从 MVC 控制器调用 REST 服务。这是一种有效的方法吗？

我认为上述两种方法可以结合使用，但我担心这会变得混乱。您是否同意采用一种方法或另一种方法更好？

抱歉，我看过很多关于是使用 WebAPI 还是 MVC 的帖子，但没有看到关于将两者结合起来的帖子。

想法？

【问题讨论】：

您的应用程序中是否已经有一个 MVC 项目，并且您正在尝试从中提取服务层？
不，这是一个新建项目。

标签： .net asp.net-mvc asp.net-web-api

【解决方案1】：

另一种方法是使用 HttpClient 类来调用 REST 来自 MVC 控制器的服务。这是一种有效的方法吗？

是的，当然。只是这段代码不应该放在你的控制器中，而应该放在你的 DAL 层中，因为控制器不应该知道数据来自哪里（平面文件、数据库、Web API ......）。

所以有两种方法：

您决定使用 HTTP 协议从 MVC 客户端应用程序使用 Web API。在这种情况下，您将为存储库（DAL 层）创建一个实现，该实现将使用 HTTP 客户端并直接返回域模型
您决定直接使用此 Web API 中包含的服务，而不发送 HTTP 请求。在这种情况下，您在 MVC 客户端应用程序中引用包含 Web API 服务层的程序集，并且该程序集直接成为 MVC 应用程序的服务层。在这种情况下，通过 HTTP 的 Web API 服务于其他客户端：javascript、移动设备，...

您选择哪种方法实际上取决于您的特定场景和要求。除了 MVC 客户端应用程序之外，您还需要支持可互操作的客户端吗？在任何情况下，首先在包含您的域模型和内容的单独程序集中定义一个服务层。然后，您始终可以通过 Web API（或 WCF 服务或其他）公开此服务层，或直接从 .NET 客户端引用它。

【讨论】：

关于第二种方法，这将如何实现？不清楚创建 webapi 的实例来调用实例方法，因为这似乎与直接调用控制器操作方法（而不是使用 RenderAction）时遇到的类似问题，因为控制器希望它从 MVC 框架实例化（对于各种上下文信息，例如 HttpRequest.Current、Principle 等）。因此，从 MVC 控制器实例化一个 webapi 类并直接调用该方法，请求不会通过 webapi 管道，所以我希望会有更多？
不是挑战你，只是试图想象这种方法会是什么样子。我记得使用 WCF，如果您从同一台机器上的另一个进程调用 WCF 服务，您可以使用命名管道+二进制序列化以获得更好的性能。你知道 WebAPI 有什么类似的东西吗？
@AaronLS，ASP.NET Web API 是为创建 RESTful Web 服务而设计的。在 REST 世界中，没有命名管道和二进制序列化这样的概念。

【解决方案2】：

我认为您有一个 MVC 项目，并且您正试图将 api 操作从 MVC 项目中分离到一个单独的 web api 项目中？如果是这种情况，您必须在开始创建单独的服务项目之前权衡好处。

一旦您创建了一个单独的 web api 项目，那么由于跨域障碍，您将无法轻松地直接从您的 MVC 项目中的 javascript 使用服务方法（当然有 JSONP 和 CORS，但它们不会这样做容易），所以你必须依赖 HttpClient 类在你的控制器中创建不必要的包装方法来与服务通信。

当您的视图需要您的 api 方法提供的数据时，值得考虑在同一个 MVC 项目中使用 api 东西，但唯一的问题是您必须使用 ApiController 而不是 Controller。

【讨论】：