关于 MVC 控制器与单独的 Web API 的架构，有多少项目？

Question

过去，我一直考虑在单独的 Web API 项目中公开将在客户端使用的方法。目前，我正在深入研究 ASP.NET Core MVC，现在了解控制器的用途。 （我来自 ASP.Net webforms 背景）

考虑到我将来可能会编写一个应用程序（例如，使用 Xamarin），我会使用来自 Core MVC 项目的大部分相同方法，因此将大部分功能分离到一个单独的 api.xxx 中是有意义的.com Web API 项目。

在我看来，ASP.NET Core MVC 控制器与 Web API 项目非常相似，我看不出在使用它们方面有很大的不同。基本上，我对是否有两个项目（核心 MVC 项目和单独的 Web API 项目）或只有一个感到困惑。

1. 我应该使用两个项目还是只使用一个？有什么优点和缺点？如果我使用两个，我根据哪些标准决定在哪里添加新代码？我可以将 Core MVC 项目中的控制器中的几乎所有（有什么例外）代码移动到 Web API 项目中吗？这是好方法还是坏方法？
2. 我应该如何处理客户端登录？我知道我可以使用 OWIN 为我的 Web API 项目获得基于令牌的身份验证，但是我应该如何将 ASP.NET Core MVC 项目的身份验证与 Web API 项目结合起来？
3. 假设我决定只为两个项目使用一个项目。如果 Xamarin 应用程序一直调用 MVC 项目而不是 Web API 项目，会有多少开销？

Answer 1

您的问题有很多要解开的内容。首先到您的一般查询：

在我看来，ASP.NET Core MVC 控制器与 Web API 项目非常相似，我看不出在使用它们方面有很大的不同。基本上，我对是否有两个项目（核心 MVC 项目和单独的 Web API 项目）或只有一个感到困惑。

那是因为在功能上没有区别。在 ASP.NET Core 中，控制器就是控制器，控制器就是控制器。 MVC/Web Api 的名称仅仅是关于style。在前者中，您将返回视图，而在后者中，您将返回 JSON 之类的内容。

现在，事实上，在 ASP.NET Core 的更高版本中，风格已经有了更多的不同。 API 控制器现在通常继承自 ControllerBase 而不是 Controller 并应用 [ApiController] 属性。然而，即使这也不是一个真正的差异。该属性只是添加了一些糖，使构建 API 更容易一些：当 ModelState 无效时自动返回 400，将默认绑定从 FromForm 切换到 FromBody 等等。这都是你可以的东西> 也可以使用 MVC。使用 ControllerBase 只会排除包含在 Controller 中的内容，这对于 API 来说是不必要的。例如，没有要返回的 View 方法，因为您不会从 API 返回视图。其他所有功能都相同。

总而言之，这几乎是关于如何您实现控制器，而不是使用 MVC 或 Web Api 的任何具体选择。

现在，关于您的具体问题：

1. 我应该使用两个项目还是只使用一个？有什么优点和缺点？如果我使用两个，我根据哪些标准决定在哪里添加新代码？我可以将 Core MVC 项目中的控制器中的几乎所有（有什么例外）代码移动到 Web API 项目中吗？这是好方法还是坏方法？

同样，这里有很多东西要解压。简单地说，没有正确的答案，坦率地说，你不必现在就决定。您可以从一个混合和匹配 MVC 和 Web Api 控制器的项目开始。然后，如果您发现特定需求，您可以随时创建一个新项目并将您的 Web Api 控制器移到那里。这仅取决于您的要求和应用程序的需求，不幸的是，除了您之外，没有人可以与之交谈。不过，我最好的建议始终是从小处着手。摆脱杂草，建造一些东西。你不是在石头上雕刻；以后可以重构任何东西。

1. 我应该如何处理客户端登录？我知道我可以使用 OWIN 为我的 Web API 项目获得基于令牌的身份验证，但是我应该如何将 ASP.NET Core MVC 项目的身份验证与 Web API 项目结合起来？

一旦您开始谈论对多个应用进行身份验证，您就真的需要开始考虑集中式身份解决方案了。有开箱即用的低配置解决方案，如 Azure AD 或 Auth0，或者您可以使用 Identity Server 推出自己的解决方案。这基本上归结为您愿意支付的费用以及您希望参与的程度。

1. 假设我决定只为两个项目使用一个项目。如果 Xamarin 应用程序一直调用 MVC 项目而不是 Web API 项目，会有多少开销？

我认为您没有正确看待这个问题。请求就是请求，问题只是规模之一。一个应用程序（一个项目）和多个应用程序之间的区别仅仅是所有请求都发往一个地方还是多个地方。但是，您始终可以垂直（资源）和水平（更多实例）扩展，即使只是一个应用程序。所以，这里的表现真的不是一个问题。无论是哪种形式，您都在以不同的方式进行扩展。

Answer 2

这取决于您的目标复杂性。 在我看来，清晰的方式是最好的。 ASP.NET Core 使用领域驱动设计概念和模式，这是一个不错的选择。 检查来自史蒂夫史密斯的Clean Architecture，并试一试。

示例如何组织它。

Answer 3

正如 Crish 已经提到的，从小处着手到单个项目，最终你可以移动东西。稍后您可以决定拥有多个项目。这是一个好的开始，但是它混合了所有的东西——你所有的 UI（cshtml 或 Angular 或任何你想要的 UI）、你所有的数据协定、API、控制器和一切。

为什么我们有 MVC 和 Web Api 技术？

这是一个很大的问题，您在该问题中有自己的答案：关注点分离。 这是设计应用程序架构时的关键。这个想法是避免在设计或代码中将不同的关注点放在一起。例如：你有一个返回视图的 MVC 控制器，你有另一个只返回数据的 API 控制器。如果你把这些东西混在一起，我认为这违反了这条规则。 在设计架构时，关注点分离是构建分层应用程序的关键组成部分。

分离不同层的所有逻辑将允许以后添加/删除任何功能，甚至允许您支持其他第三方消费者。只要将所有这些抽象都正确分组，那么您将获得从任何角度来看都是最佳的良好架构。

我的建议是使用带有 SoC 原理的 DDD 模式。但是，如果您有需要随时间扩展的大型应用程序，那么所有这些努力都是有意义的。我将开始记录您可能拥有的所有模块。如果我遵循上述模式和原则，我最终将拥有所有模块的单独 api.xxxmodule 项目 - DDD 模式。我会将 MVC、身份验证/授权 API 项目分开。

如果您遵循这 2 条原则，您的应用程序最终将拥有 单独的模块 - 每个模块都充当单独的应用程序！

希望您能从各个角度想象它们的好处。它在管理、扩展、更改、扩展、开发等方面具有巨大的优势。因为每个部分都作为一个单独的应用程序工作，所以您可以一个一个地关注所有模块，而不是混合考虑。