拆分WebApi项目和FrontEnd项目的解决方案

本文关键字：项目 解决方案 FrontEnd WebApi 拆分 | 更新日期: 2023-09-27 18:10:40

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

   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支持的解决方案时，什么时候将解决方案拆分为多个项目是明智的/不明智的?

拆分WebApi项目和FrontEnd项目的解决方案

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

前端依赖(jquery、knockout、angular....)使api过于繁重。筛选"Other"项目类型的代码可能会减慢开发速度。

当在一个项目中跨两个功能独立的项目提交时，源代码管理可能会变得有点混乱。如果您在一次提交中同时更改了API和站点，但随后又想将其中一个恢复到较早的时间点(或分别提升它们)，这将成为一个令人头痛的问题。

通过把项目放在一起，你必须一次更新所有的共享依赖(升级到一个新版本的。net ?)如果你的API代码依赖于贬值的代码，升级可能会很困难，你的网站升级可能会被推迟(反之亦然)。

如果它们在同一个项目中，你不能简单地只发布API或前端。正常情况下在您完成网站的视觉方面之前，API就已经完成并且稳定了。你不会希望每次对站点做一个小的改变时都要重新发布API。

拥有两者作为同一项目将要求您在同一web服务器上运行两者(并在同一应用程序池中!)。如果你打算让多个源访问你的API(通常是一个API的点)，那么你不会希望API因为对网站的请求而降级。这是双向的，如果你的API受到重创，你不希望你的网站变得无响应。

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

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

最后，MVC本身就是关于关注点分离和干净开发的。我想说，划分项目类型遵循这个逻辑。

我想不出有什么技术上的理由把Visual Studio解决方案分成"客户端"解决方案和"服务"解决方案。然而，在我目前的工作中，我们确实将我们的解决方案分成了两个，因为这是两个独立的团队在处理需求。所以，这对我们来说纯粹是一个组织决定。

相关文章：