MVC 应用程序和 API 控制器

Question

我的理解

基本 MVC Web 应用程序的架构（以简化方式）

(MVC View -> MVC Controller) -> Biz layer -> Data Access Layer -> DB

然后，我必须支持移动设备并为它们提供特定的信息。所以我创建适当的 API 控制器只是为了公开所需的数据。

Mobile device -> API Controller -> Biz layer -> Data Access Layer -> DB 

疑问和疑问

我已经看到（或听到）以下建议：

(MVC View -> MVC Controller) -> API Controller -> Biz layer -> Data Access Layer -> DB

或

MVC View -> API Controller -> Biz layer -> Data Access Layer -> DB

基本思想是我们将整个应用程序功能（业务层）暴露在服务之上。然后 MVC 应用程序将使用 API 控制器。

问题 1：API 创建

到目前为止，只有当我有一些数据要作为服务公开（用于移动设备等）时，我才会在我的 MVC Web 应用程序中创建一个 API 控制器。我是否缺少其他一些标准？

问题 2：API 使用情况

在上面，从 MVC 视图调用 API 控制器似乎没问题，尽管不是必须的。但是为什么要从 MVC 控制器调用 API？ （对我来说似乎错了。MVC 控制器可以直接与 biz 层对话）

问题 3：API 优势

从 API 返回的数据将被编码为 JSON 并发送到客户端。但是，我们总是可以从 MVC 控制器返回 JSONResult 以获得 MVC 视图。在纯粹的 MVC 应用程序中使用 API 控制器有什么好处吗？

Answer 1

我认为从最后一个问题开始是有意义的

从 API 返回的数据将被编码为 JSON 并发送到客户端。 然而，我们总是可以从 MVC 控制器返回 JSONResult MVC 视图。纯粹使用 API 控制器是否有优势 MVC 应用程序？

从功能的角度来看，你可以用 MVC 控制器做任何事情，就像你可以用 API 控制器做的一样，但需要更多的编码。我曾经知道一些在 MVC 控制器之上构建 API 的项目，但那是在 API 控制器发布之前。因此，如果您的控制器主要返回 HTML（渲染视图），则构建 API 控制器以返回 JSON 以填充下拉列表是没有意义的。但是，如果它是一个带有富客户端的单页应用程序（无论是否移动），或者只是一个供第三方客户端使用的 API，那么您的选择应该是 API 控制器。我建议阅读this article 以了解更多关于何时应该使用 API 控制器的信息。

以上，从 MVC 视图调用 API 控制器似乎没问题， 虽然不一定需要。但是为什么要从 MVC 调用 API 控制器？ （对我来说似乎是错误的。MVC 控制器可以与 biz 直接分层）

你是对的，这绝对是错误的。还有一层，它什么都不做，只是将浏览器请求映射到 API 中，然后将 JSON 结果映射到 HTML，或者什么都不做。此外，还有一个冗余的 HTTP 调用，从性能和维护的角度来看，这可能是一个巨大的问题。

此时，我将在我的 MVC Web 中创建一个 API 控制器 仅当我有一些数据要作为服务公开时才应用程序（对于 移动设备等）。我是否缺少其他一些标准？

我想我已经在上面回答了。因此，如果您只需要为移动设备公开一些东西，我认为您可以使用相同的控制器但具有不同的视图（移动版本），或者只是为移动设备构建单独的 UI 层（视图和控制器）。除非您的移动 UI 是经典的单页应用程序，否则我不明白您为什么要使用 API 控制器。此外，如果您的目标是从长远来看为移动设备公开所有功能，请查看响应式设计。这样您就可以为所有设备使用相同的视图和控制器。

希望对你有帮助！