仅使用 HttpClient 围绕 RESTful API 构建 MVC 应用程序是否明智？答案

【问题标题】：Is it wise to build an MVC app around a RESTful API using nothing but HttpClient?仅使用 HttpClient 围绕 RESTful API 构建 MVC 应用程序是否明智？
【发布时间】：2018-09-04 21:38:59
【问题描述】：

我的老板想要一个完整的 REST API 用于我们的新项目。但是，他也想要一个 UI 并且我们的截止日期不是很慷慨。学习一个体面的前端框架（Angular、React、Vue）可能会花费一些时间。

他问我们是否可以完全使用 MVC 与 REST API 对话。我向他解释说，MVC 意味着视图与控制器紧密耦合。

他问为什么我们不能完全构建 REST API，然后制作一个在控制器（或服务类）中使用 HttpClient 的 MVC 应用程序来访问 API。这是个坏主意吗？我告诉他这似乎是另一个需要维护的大层，并且大多数人可能正在使用一个不错的前端框架与他们的后端对话。

我也觉得我对其他人如何处理这种情况还不够了解。所以那些必须为所有新应用程序提供 REST API 的人。你如何为它构建你的用户界面？我们正在使用 Swagger，因此如果有帮助，可以生成 TypeScript 或 C# 客户端。

【问题讨论】：

所以他想要 REST API，但唯一会调用该 API 的将是您的 MVC 控制器？

标签： c# asp.net-mvc rest architecture

【解决方案1】：

他在问我们是否可以完全使用 MVC 与 REST API 对话。

是的，这很常见。当前版本的 MVC asp.net-core-mvc 基本上是 MVC/WebApi 封装在一个Framework中。

我向他解释说，MVC 意味着视图与控制器紧密耦合。

否。除了构建模型和路由到视图之外，控制器实际上与其他任何事情无关。 我从头开始构建的每个项目，视图不了解控制器，并且大多数时候只知道传递给它的模型（有时甚至没有模型） .有人可以将视图与控制器紧密耦合，但我不建议这样做。

他问为什么我们不能完全构建 REST API，

你可以，这很容易，我几乎一直都这样做。

制作一个在控制器（或服务类）中使用 HttpClient 来访问 API 的 MVC 应用程序。

这是一个坏主意 如果他们是同一个项目。没有充分的理由添加另一个网络层。它没有提供任何价值。

我也觉得自己不太了解其他人如何处理这种情况

所以这真的是我个人的意见。我从 jQuery 2.0 版开始使用 Asp.net-mvc。我开始使用带有KnockoutJS 的 MVC，它将 95% 的数据移动到 API 调用中，并且我的大多数视图都没有模型。我曾使用 Angular 参与过项目，但基于我非常有限的知识，它更难上手，而且似乎需要更多才能完成一些简单的事情。我目前正在使用 Kendo（类似于 Knockout MVVM），它完成了这项工作。在所有这些使用前端 Javascript 框架的实例中，我的大部分视图都是无模型的，完全依赖于 API。

如果我要在有限的时间内开始一个新项目，恕我直言，MVC/WebAPI + Knockout 非常简单。同样，这只是我根据自己的喜好和经验得出的看法。

但是 警告：咆哮

他为什么想要它作为 REST Api？ 说真的，当任何类型的经理告诉我应该使用什么工具来构建解决方案时，我真的很讨厌。这是我们这个时代的新/旧 SOA（面向服务的架构）。有时，无缘无故地添加需求只会增加更多时间/资源来获得解决方案。

例如：

经理：我需要将托盘运送到目的地。创造一辆可以尽可能高效地将一个托盘运送到目的地的车辆。哦，它需要 4 个门！

我：为什么f需要四扇门？因为你喜欢4门？因为这是新的热潮？

【讨论】：

控制器是否不需要构建一个高度特定的视图模型，专门为单个视图设计？在我看来，控制器与其视图紧密相连。 JSON API 是必需的，因此外部部门可以 CRUD 应用程序数据。这不仅仅是一个下意识的架构决策。
不要将数据流与依赖项混淆。我可以创建一个依赖于人员类的人员视图。什么控制器创建那个人类并不重要。出于SRP 的原因，我只会创建一个PersonController，但这是出于架构原因，而不是基于紧密耦合的任何类型的要求。
另外，在我使用淘汰赛之前，回到过去（如 2008 年），我的 MVC 代码可以将视图或视图模型返回为 Json。因此，用户会转到该页面，它会使用数据加载 MVC 视图，当有人点击下一个或其他什么时，我只需下载 JSON 并更新视图而无需重新加载页面。
是的，我们已经用 Angular 1.x 做到了这一点。将@model 序列化为 JSON，然后将其写入到脚本标记中的页面中。然后 Angular 可以把它捡起来。这是向无状态 MVC 应用程序添加一些 JS 功能的好选择。
好吧，如果你已经完成了 Angular，使用 MVC 来传递 Html 和 REST 数据。看起来很简单。

【解决方案2】：

如果您的后端位于关系数据库中，并且您的截止日期确实很紧，那么这里有一种替代手动编码 API 端点的方法。看看 SlashDB，它将数据库包装在一个直观的 API 中用于读写，并提供 HTML 的 GUI。 In 还具有适用于 AngularJS 的 SDK，并且通常易于用于任何框架中的任何 Web/移动应用程序。

https://slashdb.com

这可能只是为您赢得了足够的时间来完善您选择的框架中的网络应用程序，而不是将这些时间投入到数据访问代码中，这些代码通常对用户来说是“不可见的”。

免责声明：SlashDB 是我公司的产品。

【讨论】：

现在这是一款非常酷的产品。编写 CRUD 应用程序应该像 2018 年那样完全自动化。数据库设计应该花费所有时间和努力。

【解决方案3】：

我的老板想要一个完整的 REST API 用于我们的新项目。但是，他也想要一个 UI，我们的截止日期不是很宽。

如果您使用 HTML 作为您的媒体类型，您将能够使用任何您喜欢的网络浏览器来呈现 UI。

一些 json 超媒体格式也可能有浏览器；例如HAL 作者 Mike Kelly 有一个browser 的 github 项目。

【讨论】：

【解决方案4】：

学习一个体面的前端框架（Angular、React、Vue）可能证明花费的时间有点太长了。

MVC 是一个不错的前端框架。你不同意吗？

他问我们是否可以完全使用 MVC 与 REST API 对话。一世向他解释说，MVC 意味着视图与控制器。

他是对的，MVC 不会将您与任何事物紧密耦合。糟糕的编程紧密耦合。

他问为什么我们不能完全构建 REST API，然后制作一个在控制器（或服务）中使用 HttpClient 的 MVC 应用程序 class) 来访问 API。这是个坏主意吗？

MVC 到 API 很常见。正如你的老板所说，你的 MVC（UI 层）控制器使用 HttpClient 实例连接到你的 API。他已经把它钉在这里了。

你的老板所描述的是微软堆栈中非常常见的事情。

【讨论】：

非常感谢您的回答。这真的很有帮助。我看到的东西是这样的：github.com/gothinkster/realworld，我没有看到任何用于他们 UI 的 Core MVC 应用程序。此外，以各种方式谷歌搜索我的问题并没有产生很多关于完全在 MVC 中使用 REST API 的教程或示例。他们中的大多数人教授构建混合 MVC/REST API 应用程序。似乎很多人会在现代 JS 应用程序中使用他们的 REST API。但如果上市时间很重要，而且这或多或少是一个巨大的 CRUD 应用程序，那么 MVC 可能是完成这项工作的最佳工具。
通过 MVC 到 API，你的意思是你实现了 rest api，然后从控制器调用它？但是这样做有什么意义，为什么不直接从网页调用那个rest api呢？
@Evk...Page 调用 MVC 控制器并调用 API 控制器。他当然可以从网页调用 API，但可能有理由通过 MVC 控制器对其进行路由。
@VictorioBerra ...趋势肯定是 JS 应用程序直接调用 API，但 MVC 到 API 仍然是一个很好的方法。为工作选择工具。
正确。 @Evk 这是我问题的本质。 Angular vs MVC（在控制器中使用 HttpClient）。更具体地说，是后来的正常，常见的。我从事网络应用程序已经有很长时间了，但我从未见过自己（或其他任何人）将我的 MVC 应用程序与其数据层分离并在后端通过 HTTP 连接它。