C# 在解决方案中拆分WebApi项目和前端项目

我有一个针对我正在构建的移动应用程序的解决方案-到目前为止，这包括两个项目：

   1) WebAPI for API / DAL / SQL etc
   2) Web for single-page front-end

Web项目调用WebAPI项目。计划是为Windows 8应用程序创建另一个项目，为WP8应用程序创建另一个项目，等等

---

这在开发过程中工作正常，但在COR、部署等方面变得相当复杂（Web是从不同于WebAPI的端点提供的，这两个Azure网站）。我的问题是——当设计一个由REST-ish API支持的解决方案时，将解决方案拆分为多个项目是明智还是不明智的

我想不出有什么技术理由可以将VisualStudio解决方案分为“客户端”解决方案和“服务”解决方案。然而，在我当前的工作中，我们确实将解决方案分成了两部分，因为这是两个独立的团队处理需求。因此，对我们来说，这纯粹是一个组织决策。

我总是将API和前端分成单独的项目，原因如下：

前端依赖项（jquery、knockout、angular…）使api比需要的更重。筛选“其他”项目类型的代码可能会减慢开发速度

在一个项目中跨两个功能上独立的项目提交时，源代码管理可能会有点混乱。如果您在一次提交中同时更改了API和站点，但又想将其中一个恢复到较旧的时间点（或单独升级），这将成为一个令人头痛的问题

通过将项目放在一起，您必须一次更新所有共享依赖项（升级到新版本的.NET？）。如果您的API代码依赖于已折旧的代码，则升级可能会很困难，并且您的网站升级可能会被推迟（反之亦然）

如果它们在同一个项目中，则不能轻松地仅发布API或前端。正常地 在你搞乱网站的视觉方面之前，API将很早就完成并稳定了。您不会希望在每次对站点进行微小更改时都必须重新发布API而受到阻碍

将两者作为同一个项目需要在同一个Web服务器上（以及在同一个应用程序池中！）运行。如果您将有多个源访问您的API（通常是API的点），那么您不会希望API因对网站的请求而降级。这是双向的，如果您的API受到严重影响，您不希望您的站点变得无响应

由于它们将在相同的应用程序池中运行，因此它们也将作为相同的用户运行。出于安全目的，您可能希望API应用程序池作为单独的服务帐户运行，该帐户具有对数据源的集成身份验证访问权限。然后，您可以锁定网站用户帐户，使其无法访问外部资源

由于MVC webapi模板提供了前端的所有依赖项和配置，因此将它们放在一起似乎是合乎逻辑的，但仅仅因为它们使它变得简单并不意味着应该这样做。我通常将此模板中提供的前端剥离出来，并将其制作成一个简单的页面来描述如何使用API

---

最后，MVC本身就是关注点分离和清洁开发。我想说，分离项目类型遵循这一逻辑。

谢谢。因此，我认为，在您看来，托管和本地（localhost:2020和localhost:2021）以及CORS的不同端点的头痛是值得关注的，是的，绝对值得。随着项目规模的扩大，分离将很快得到回报。此外，对于不同的端点，您的消费者可以选择直接访问他们想要的（API或前端），而不必知道其他端点。此外，尽管CORS总是令人头痛，但在webapi中编写处理程序是非常简单的。有大量在线文档用于编写CORS处理程序，允许您指定特定主机、所有主机等的访问权限。