在解决方案中将WebApi项目和前端项目分离

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 的解决方案中，分解解决方案为多个项目何时明智/不明智？

- SB2055

Answer 1

我通常将API和前端分成两个独立的项目，原因如下：

- 前端依赖项（jQuery、Knockout、Angular等）会使API比必要的重量更重。在“其他”项目类型中检索代码可能会减缓开发速度。 - 在一个项目中跨越两个功能上独立的项目进行提交时，源代码控制可能会变得有点混乱。如果您同时更改了API和站点，但随后想要将其中一个还原到早期时间点（或单独提升它们），这将成为一个头痛的问题。 - 如果将项目放在一起，则必须一次性更新共享依赖关系（升级到新版本的.NET？）。如果您的API代码依赖于已废弃的代码，升级可能会很困难，您的网站升级可能会被拖延（反之亦然）。 - 如果它们在同一个项目中，则无法轻松地发布API或前端。通常，API将在网站视觉方面进行微小更改之前就已经完成并稳定。您不会希望每次进行小型站点更改时都必须重新发布API而受到限制。 - 将它们作为同一项目需要您在同一Web服务器上运行两者（并位于同一应用程序池中！）。如果您要让多个来源访问您的API（通常是API的目的），那么您不希望由于对网站的请求而降低API的质量。如果API受到重击，同样也不希望您的站点变得无响应。 - 由于它们将在同一个应用程序池中运行，因此它们也将作为同一用户运行。出于安全考虑，您可能希望将API应用程序池作为具有集成身份验证访问数据源权限的单独服务帐户运行。然后，您可以锁定网站用户帐户并不允许其访问外部资源。 - 由于MVC WebAPI模板提供了所有前端的依赖项和配置，因此将它们放在一起似乎很合理，但仅仅因为它们使它变得容易，并不意味着应该这样做。我通常会剥离此模板中提供的前端，并将其制作成简单页面以描述如何使用API。

归根结底，MVC本身就是关注点分离和干净开发。我认为按照项目类型进行分离也遵循了这个逻辑。

- vesuvious

---

谢谢您。那么，根据您的意见，不同的端点（本地托管和本地主机：2020和本地主机：2021）以及CORS的头疼问题是值得关注的吗？ - SB2055

是的，绝对没错。随着项目规模的扩大，分离将很快得到回报。此外，使用不同的端点，您的消费者可以选择直接访问他们想要的内容（API或前端），而无需了解其他端点。 - vesuvious

此外，尽管CORS总是令人头痛，但在WebAPI中编写处理程序非常直接。有大量在线文档可用于编写CORS处理程序，允许您指定特定主机、所有主机等访问权限。 - vesuvious

Answer 2

我无法想到为何要将Visual Studio解决方案分为“客户端”解决方案和“服务端”解决方案的技术原因。然而，在我目前的工作中，我们将解决方案拆分成两个部分，因为有两个独立的团队负责开发需求。所以，对我们来说，这纯粹是一项组织上的决策。

- Ralph Allan Rice