Azure 应用程序 - 分布式体系结构 - 1 个 API 层与 2 个 API 层 - 设计决策答案

【问题标题】：Azure Apps - Distributed Architecture - 1 API Layer vs 2 API Layers - Design decisionsAzure 应用程序 - 分布式体系结构 - 1 个 API 层与 2 个 API 层 - 设计决策
【发布时间】：2016-09-17 15:07:52
【问题描述】：

背景在完成 Azure 应用服务教程 (https://azure.microsoft.com/en-gb/documentation/articles/app-service-api-dotnet-get-started/) 中的 API 应用和 ASP.NET 入门之后，我们今天遇到了一个架构问题，围绕着将待办事项列表应用程序 API 层拆分为中间层的设计决策API 应用和数据层 API 应用。

在使用分布式架构构建应用程序时，应注意哪些事项以了解何时应在 API 层中发生这种类型的分离？

问这个问题的另一种方式是，在构建应用程序时，使用单独的中间层 API 层和数据层 API 应用程序的优缺点是什么？

其他问题 我读过Web apps architecture: 1 or n API question（见下面的链接），虽然很有见地，但与我们提出的问题略有不同。我们谈论的是一个单独的域，它具有用于中间层（逻辑）和数据层的单独 API 层。

Web apps architecture: 1 or n API

【问题讨论】：

标签： azure asp.net-web-api architecture design-decisions azure-app-service-envrmnt

【解决方案1】：

这当然取决于。决定是否构建我所说的“基础设施服务”在很大程度上取决于您的需求和您的应用程序。

基础设施层服务通常比业务逻辑层服务获得更多的重用。它们很容易重新组合成新的应用程序。最常见的例子是将管理界面构建为单独的应用程序。

如果您已经在组织中构建了多个应用程序，并且发现经常重复使用，那么我会认真考虑基础架构服务。如果您的组织正在编写它的第一个应用程序，并且您没有看到它扩展到其他接口，那么也许只是将您的数据访问隔离在 DAO 模式中，稍后将其重构为独立服务相当简单。

【讨论】：

感谢 Rob 的解释，这正是我想要的。在我们正在研究的特定场景中，我现在可以看到，在可预见的未来，我们不会意识到使用基础设施服务的好处——因此具有 DAO 模式的单个 API 层将是我们的选择。再次感谢！

【解决方案2】：

我认为示例设计有些混乱。在现实世界中，我还没有见过这样的设计，因为设计看起来好像每个函数都是 http/rpc 调用？

我的经验是 SPA 使用公共 API（或网关 API），然后调用您的内部 API/微服务来汇总结果。您的微服务可能有 DAO，最重要的是，业务逻辑

【讨论】：