c# - 在解决方案中拆分 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 网站)。我的问题是 - 在构建由 REST-ish API 支持的解决方案时，何时将解决方案拆分为多个项目是明智/不明智的？

Answer 1

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

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

在一个项目中跨两个功能独立的项目提交时，源代码控制可能会变得有点困惑。如果您在一次提交中同时更改了 API 和站点，但随后想要将其中一个恢复到较旧的时间点(或单独升级它们)，这将变得令人头疼。

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

如果它们位于同一项目中，您将无法轻松地仅发布 API 或前端。通常情况下在您不再搞乱网站的视觉效果之前，API 就已经完成并稳定了。您不希望每次对网站进行微小更改时都必须重新发布 API，从而受阻。

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

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

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

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