Question

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

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

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

这在开发过程中运行良好，但在CORS，部署等方面变得非常复杂（Web是从与WebAPI不同的端点提供的 - 两个Azure网站）。我的问题是 - 在构建一个由REST-ish API支持的解决方案时，何时将解决方案拆分为多个项目是明智/不明智的？

Answer 1

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

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

在一个项目中提交两个功能独立的项目时，源代码控制可能会有点混乱。如果您在一次提交中更改了API和网站，但又希望将其中一个恢复到较旧的时间点（或单独推广它们），那么这将成为一个令人头痛的问题。

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

如果它们位于同一个项目中，则无法轻松发布API或前端。一般在你弄乱网站的视觉方面之前，API将会完成并保持稳定。每次进行小的站点更改时，您都不希望因重新发布API而受阻。

将两者作为同一个项目需要您在同一个Web服务器上运行（并且在同一个应用程序池中！）。如果您打算使用多个来源（通常是API），那么您不希望API因网站请求而降级。这有两个方面，如果你的API受到重创，你不希望你的网站没有响应。

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

由于MVC webapi模板提供了前端的所有依赖关系和配置，将它们放在一起似乎是合乎逻辑的，但仅仅因为它们使它变得简单并不意味着它应该以这种方式完成。我通常会删除此模板中提供的前端，并将其放入一个简单的页面来描述如何使用API。

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

Answer 2

我无法想到将Visual Studio解决方案拆分为＆＃34;客户端的技术原因。解决方案和＆＃34;服务＆＃34;解。但是，在我目前的工作中，我们确实将解决方案分成了两个，因为它是两个独立的团队来处理需求。所以，这纯粹是我们的组织决定。