广泛而普遍的问题：
我们有一个快速接近旧版状态的应用。它有三个客户端：Windows应用程序，浏览器（网站）和移动。数据访问层充其量是复杂的，并且多年来一直在有机地发展。
我们希望重新构建整个事物。 Windows应用程序将消失（＆＃39;导致谁那个更多？）我们将只有基于浏览器的网站和移动应用程序，两者都将消耗（截至今天，不存在的API层。如果他们希望自己进行集成，那么这个API层也将部分暴露给第三方。
这是我的问题：
这个API层是什么样的？而且，我的意思是......让我们从Visual Studio解决方案开始吧。 API是一个单独的网站吗？那么在IIS上，是否会有两个站点......一个用于面向公众的网站，另一个用于API层？
或者，API应该是主网站中的.dll，并且端点URL是否是IIS中单个网站的一部分？
最终，我们希望更新并发布一个不会影响另一个的w / o。我只是不确定如何构建整个事物。
（如果重要：每个客户都有自己的安装，无论是在他们的网络上本地安装，还是托管云。所有数据库都是单租户。）
答案 0 :(得分：2)
我认为一个单项解决方案有多个项目。
如果您将API作为其他网站，您可以轻松地向您的API添加Swagger和Swashbuckle等内容 https://github.com/domaindrivendev/Swashbuckle
这将使文档变得简单。
从这里开始，您可能希望将您的业务逻辑（执行特定事务的事情）放在第三个项目中。
从这里你有两个选择。网页可以使用您自己的API，也可以引用您的业务逻辑项目。
如果面向公众，其他网站上的API会提供一些额外的好处： 域名分离 负载平衡和增加保护 没有站点影响的资源限制和限制
这些项目非常有趣，所以请考虑您的选择以及最适合的选择。
我希望这有帮助！
答案 1 :(得分：2)
我更喜欢这样做的方法是使用单独的API项目。你将API项目发布到一个网址，将网站发布到另一个网址。这使您可以开发两个没有干扰的应用程序。
说，我正式将API的逻辑放在服务层（SOA架构）中。我的api项目只是将输入传递给sercice层并通过服务响应进行响应。这样你就可以在公共和私人之间分离api，并且仍然在一个地方包含所有逻辑。
通常我会创建一个Api包装器作为处理所有API调用的单独项目，因此其他开发人员可以使用API包装器（只是为了让我的感觉开发人员更容易与api交谈）