关于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项目非常相似，在使用它们方面我看不出有很大的不同。基本上，我对于是两个项目（Core MVC项目和单独的Web API项目）还是只有一个项目感到困惑。

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

Answer 1

您的问题有很多需要解决的问题。首先对您的一般查询：

  

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

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

实际上，在更高版本的ASP.NET Core中，样式有所不同。现在，API控制器通常继承自ControllerBase而不是Controller并应用了[ApiController]属性。但是，即使这不是真实差异。该属性只是增加了一些糖，使构建API更加容易：ModelState无效时自动返回400，将默认绑定从FromForm切换为FromBody，依此类推。这些都是您< em>也可以和MVC一起使用。使用ControllerBase仅排除Controller中包含的API不需要的内容。没有View方法可以返回，因为例如您不会从API返回视图。其他所有功能都相同。

总之，总的来说，这与实现控制器的方式有关，而不是使用MVC或Web Api的任何特定选择。

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

  

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

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

  

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

一旦开始谈论对多个应用程序进行身份验证，您确实需要开始研究集中式身份解决方案。提供低配置解决方案，例如Azure AD或Auth0，或者您可以使用Identity Server自行开发。基本上可以归结为您愿意支付的价格以及您希望参与的程度。

  

  
1. 让我们假设我决定只使用一个项目。如果Xamarin应用程序始终都调用MVC项目而不是Web API项目，那么会有多少开销？
  

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

Answer 2

这取决于您要达到的复杂性。 以我的观点，最好的明确方法是。 使用使用域驱动设计概念和模式的 ASP.NET Core ，这是一个不错的选择。 从史蒂夫·史密斯（Steve Smith）检查Clean Architecture，然后尝试一下。

示例如何组织它。

Answer 3

正如Crish所说的那样，从小开始到单个项目，最终您可以移动东西。稍后，您可以决定拥有多个项目。这是一个很好的开始，但是它混合了所有东西-您的所有UI（cshtml或angular或您想拥有的任何UI），所有数据协定，API，Controller和所有东西。

  

为什么我们要使用MVC和Web Api技术？

这是一个大问题，您有一个答案：关注点分离。 这是设计应用程序体系结构的关键。这样做的目的是避免在设计或代码中共同定位不同的关注点。例如：您有返回视图的MVC控制器，而另一个API控制器仅返回数据。如果将这些内容混合在一起，我认为这是违反该规则的。 在设计架构时，关注点分离是构建分层应用程序的关键组成部分。

将所有逻辑分隔在不同的层上将允许以后添加/删除任何功能，甚至还可以支持其他第三方使用者。只要对所有这些抽象进行了适当的分组，就可以实现从任何角度来看都是最佳的良好架构。

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

  

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

希望您可以从所有角度想象它们的好处。在管理，扩展，更改，扩展，开发等方面，它具有巨大的好处。由于每个部分都作为一个单独的应用程序工作，因此您可以一个个地专注于所有模块，而不必三思而后行。