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

【问题标题】：Splitting up WebApi project and FrontEnd project in Solution在解决方案中拆分 WebApi 项目和 FrontEnd 项目
【发布时间】：2014-08-18 02:08:52
【问题描述】：

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

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

【问题讨论】：

【解决方案1】：

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

【讨论】：

【解决方案2】：

出于以下几个原因，我总是将 API 和前端拆分为单独的项目：

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

在一个项目中跨两个功能独立的项目提交时，源代码管理可能会有点混乱。如果您在一次提交中同时更改 API 和站点，但又想将其中一个恢复到较旧的时间点（或单独提升它们），这将变得令人头疼。

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

如果它们在同一个项目中，您不能轻松地仅发布 API 或前端。一般在您完成网站视觉方面的混乱之前，API 将完成并保持稳定。您不希望每次对网站进行小的更改时都必须重新发布 API，从而受到阻碍。

将两者都作为同一个项目需要您在同一个网络服务器上运行它们（并且在同一个应用程序池中！）。如果您将有多个来源访问您的 API（通常是 API 的点），那么您不希望 API 由于对网站的请求而降级。这是双向的，如果您的 API 受到重创，您不希望您的网站变得无响应。

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

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

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

【讨论】：

谢谢。所以我认为在您看来，托管和本地（localhost:2020 和 localhost:2021）和 CORS 的不同端点令人头疼，值得关注点分离？
绝对是的。随着项目变得越来越大，分离将很快得到回报。此外，通过不同的端点，您的消费者可以选择直接访问他们想要的（API 或前端），而无需了解其他端点。
此外，尽管 CORS 总是令人头疼，但在 webapi 中编写处理程序非常简单。有大量在线文档可用于编写 CORS 处理程序，这些处理程序允许您指定某些主机、所有主机等的访问权限。