我们应该在同一解决方案中从 MVC 应用程序调用 Web API 吗？

Question

我正在开发一个具有移动应用程序的 MVC 项目，所以很清楚我们必须使用 Web API 才能在移动应用程序中使用它。

在我们开始开发网站的时候创建了API之后，我们很困惑并且讨论过是使用API​​还是直接访问Business对象。我们最终得到了更有经验的开发人员的意见，以使用 Web API 而不是直接使用业务对象。

我对此解决方案结构感到困惑。

1) 为什么我们应该使用 Web API 并发出 HTTP 请求（这很耗时）来获取或放置数据，而不是直接在同一解决方案中的业务对象。

2) 在争论之后，他们说如果客户想要在不同的云服务器上托管 API 和 Web 并仅在 API 上应用缩放，或者他可能想要有不同的 url 来访问 API 和 Web（这是合乎逻辑的） .那么在这种情况下，我们应该在同一解决方案中从 MVC 应用程序调用 Web API 吗？

3) 如果我们将 API 和 Web 托管在不同的主机上，这意味着我们的 Web 将使用 WebClient 并在每个导航上都有 HTTP 调用。对吗？

4) 如果我们要在不同的服务器上同时创建 API 和 Web 托管业务对象，那么如果 BL 发生变化，则需要在两台服务器上更新构建。

5) 或者我们应该只为API创建一个项目，并且可以添加视图或html页面来开发Web界面，这样我们就可以直接从ajax调用API。

据我所知，#5 是最好的解决方案，或者 API 仅适用于第 3 方访问。如果我们在同一个解决方案中有 DB、EF、数据层和业务层，那么我们不应该使用 API 进行 HTTP 调用并直接访问业务对象。 （如果我错了，请纠正我）当移动应用程序或桌面或任何人想要访问应用程序时需要 API，以便我们可以拥有相同的存储库和数据层。

在我的场景中，我必须创建 API，因为我们也有移动应用程序，并且在项目 API 方面，我们称为业务层（单独的项目），业务层与数据访问层（单独的项目）进行通信。所以我的问题是，如果我们将 API 和 Web 托管到不同的服务器上，那么调用作为 HTTP 请求的 API 可能需要更长的时间，而不是在我们创建项目时使用来自业务层的方法，并且我们拥有业务层的 .dll。在 API 控制器中，我们只是将业务输出转换为 json 格式。

我在网上搜索过，但没有得到令人信服的答案。我发现了一个博客 http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx 讨论同一点，但在该博客中我的问题是为什么我们需要考虑场景 #3？

Answer 1

我认为您已经以书面形式回答了自己的问题，但实际上这完全归结为您的要求，也许更重要的是，您的应用程序的策略是什么。

首先，使用 Web Api 而不是直接访问业务对象（我认为您的意思是通过视图模型等）只有在您控制数据客户端的访问时才有意义。

如果您只需要在特定应用程序中使用来自客户端的数据，那么在同一个项目中托管 Web API 是有意义的。有时，例如在构建 SPA 或富客户端 Web 应用程序时，在同一个项目中使用 Web Api 就足够了，因为它们仅供该应用程序使用。

如果您看到对同一应用程序（移动设备、平板电脑、网络等）的不同版本的需求，那么将 Web Api 移动到单独的项目是有意义的，因为每个应用程序都可以访问相同的 API。此 Web Api 将包含您的数据访问和业务逻辑层。这允许您的项目完全分离，并提供最大的可重用性，并确保项目不同版本之间的数据一致性。显然，通过这种设置，您的 Web Api 层是独立的，可以单独进行测试/部署/扩展。

因此，总而言之，您需要考虑您的需求并评估您可用的技术来实现这些需求。使用上述内容，我希望您了解 Web Api 适合的位置以及它可以提供什么。