过去，我一直在考虑公开将在单独的Web API项目中在客户端使用的方法。目前，我正在更深入地研究ASP.NET Core MVC，现在了解控制器的用途。 （我来自ASP.Net Webforms背景）
鉴于我将来可能会编写一个应用程序（例如，使用Xamarin），而我将使用Core MVC项目中的大多数相同方法，因此将大多数功能分成一个单独的api.xxx.com网站是有意义的API项目。
从我的角度来看，ASP.NET Core MVC控制器与Web API项目非常相似，并且在使用它们方面我看不出有很大的不同。基本上，对于是否有两个项目（Core MVC项目和单独的Web API项目）还是只有一个项目，我感到困惑。
我应该使用两个项目还是一个？优点和缺点是什么？如果使用两个，则根据哪个条件决定在哪里添加新代码？我可以将几乎所有（例外）代码从Core MVC项目中的控制器移到Web API项目中吗？这是好方法还是坏方法？
我应该如何处理客户端登录？我知道我可以为我的Web API项目使用OWIN获得基于令牌的身份验证，但是如何将来自ASP.NET Core MVC项目的身份验证与Web API项目结合起来？
假设我决定对两个项目都使用一个项目。如果Xamarin应用程序始终都调用MVC项目而不是Web API项目，那么会有多少开销？
最佳答案
您的问题有很多需要解决的问题。首先对您的一般查询：
从我的角度来看，ASP.NET Core MVC控制器与Web API项目非常相似，并且在使用它们方面我看不出有很大的不同。基本上，对于是否有两个项目（Core MVC项目和单独的Web API项目）还是只有一个项目，我感到困惑。
那是因为在功能上没有区别。在ASP.NET Core中，控制器就是控制器。 MVC / Web Api的名称仅与样式有关。在前者中，您将返回视图，而在后者中，您将返回类似JSON的内容。
现在说实话，在更高版本的ASP.NET Core中，样式有所不同。 API控制器现在通常继承自ControllerBase而不是Controller并应用了[ApiController]属性。但是，即使这不是真正的区别。该属性只是增加了一些糖，使构建API变得更加容易：当ModelState无效时自动返回400，将默认绑定从FromForm切换为FromBody，等等。这一切都可以通过MVC完成。使用ControllerBase仅排除Controller中包含的API不需要的内容。没有View方法可以返回，因为例如，您不会从API返回视图。其他所有功能都相同。
总而言之，这几乎与您如何实现控制器有关，而不是使用MVC或Web Api的任何特定选择。
现在，关于您的具体问题：
我应该使用两个项目还是一个？优点和缺点是什么？如果使用两个，则根据哪个条件决定在哪里添加新代码？我可以将几乎所有（例外）代码从Core MVC项目中的控制器移到Web API项目中吗？这是好方法还是坏方法？
同样，这里有很多要解压的东西。简而言之，没有正确的答案，坦率地说，您不必立即决定。您可以只从混合和匹配MVC和Web Api控制器的一个项目开始。然后，如果发现特定需求，则始终可以创建一个新项目并将Web Api控制器移到那里。这仅取决于您的要求和您的应用程序的需求，不幸的是，只有您才能与您交谈。不过，我最好的建议始终是从小处着手。摆脱杂草，只是建立一些东西。您不是在石头上雕刻；任何东西都可以在以后重构。
我应该如何处理客户端登录？我知道我可以为我的Web API项目使用OWIN获得基于令牌的身份验证，但是如何将来自ASP.NET Core MVC项目的身份验证与Web API项目结合起来？
一旦开始讨论对多个应用程序进行身份验证，您确实需要开始研究集中式身份解决方案。提供低配置解决方案，例如Azure AD或Auth0，或者您可以使用Identity Server自行开发。它基本上可以归结为您愿意支付的价格以及您想成为什么样的人。
假设我决定对两个项目都使用一个项目。如果Xamarin应用程序始终都调用MVC项目而不是Web API项目，那么会有多少开销？
我认为您没有以正确的方式看待这个问题。请求就是请求，问题只是规模之一。一个应用程序（一个项目）和多个应用程序之间的区别仅仅是所有请求都发送到一个地方还是多个地方。但是，即使仅一个应用程序，也始终可以垂直（资源）和水平（更多实例）扩展。因此，性能在这里并不是真正的问题。无论哪种形式，您都在以不同的方式扩展。