在解决方案中拆分WebApi项目和FrontEnd项目

Question

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

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

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

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

Answer 1

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

前端依赖(jquery,knockout,angular ....)使api比必要的重.筛选"其他"项目类型的代码可能会降低开发速度.

在一个项目中提交两个功能独立的项目时,源代码控制可能会有点混乱.如果您在一次提交中更改了API和网站,但又希望将其中一个恢复到较旧的时间点(或单独提升它们),那么这将变得令人头疼.

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

如果它们位于同一项目中,则无法轻松发布API或前端.通常情况下,在您完成网站的可视化方面之前很久就会完成并保持稳定.每次进行次要站点更改时,您都不希望因重新发布API而受阻.

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

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

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

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