我有一个针对正在构建的移动应用程序的解决方案-到目前为止，该解决方案包含两个项目：
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支持的解决方案时，何时将解决方案拆分为多个项目是明智/不明智的做法？
由于以下几个原因，我总是将API和前端划分为单独的项目：
前端依赖项（jquery，knockout，angular ....）使api变得比必需的更重。在“其他”项目类型的代码中进行筛选可能会减慢开发速度。
在一个项目中的两个功能上分开的项目中进行提交时，源代码控制可能会造成一些混乱。如果您在一次提交中同时更改了API和站点，但是又想将其中之一恢复到较早的时间点（或单独进行升级），这将很麻烦。
通过将项目放在一起，您必须一次更新所有共享的依赖项（升级到.NET的新版本？）。如果您API的代码依赖于折旧代码，则升级可能会很困难，并且网站升级可能会受阻（反之亦然）。
如果它们在同一个项目中，则不能仅发布API或前端。通常，在您弄乱了网站的视觉外观之前，API就会完整且稳定。您不希望每次进行较小的站点更改时都不得不重新发布API，从而不会受到阻碍。
将两者作为同一个项目需要您在相同的Web服务器（和相同的应用程序池！）中运行它们。如果您将有多个来源访问您的API（通常是API的关键点），那么您不希望由于网站请求而使API降级。这是双向的，如果您的API受到重击，则您不希望您的网站变得无响应。
由于它们将在同一应用程序池中运行，因此它们也将以同一用户身份运行。为了安全起见，您可能希望API应用程序池作为对您的数据源具有集成身份验证访问权限的单独服务帐户运行。然后，您可以锁定网站用户帐户，并使其无法访问外部资源。
由于MVC webapi模板为前端提供了所有依赖关系和配置，将它们组合在一起似乎合乎逻辑，但是仅仅因为它们使操作变得简单并不意味着应该那样做。我通常会精简此模板中提供的前端，并将其分成一个简单的页面来描述如何使用API。
最后，MVC本身就是关注点分离和清洁开发。我会说，分离项目类型遵循此逻辑。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句