.Net Core Rest API 最佳实践答案

【问题标题】：.Net Core Rest API Best practise.Net Core Rest API 最佳实践
【发布时间】：2018-04-27 23:25:39
【问题描述】：

我想知道以下 API 结构的最佳做法是什么：

OrderItemDepartment 与 OrderItemSection 具有一对多关系，而 OrderItemSection 又与 OrderItem 具有一对多关系。

将 api 划分为控制器，每个控制器都有 CRUD 操作，例如：

OrderItemDepartmentsController
- 获取：OrderItemDepartments。
OrderItemSectionsController
- 获取：OrderItemSections。
OrderItemsController
- 获取：OrderItems。

..或者有一个控制器通过路由为 OrderItems、Departments 和 Sections 提供服务：

OrderItemsController
- 获取：订单项/部门
- 获取：OrderItems/Sections
- 获取：OrderItems*

【问题讨论】：

我认为你应该避免使用上帝控制器。上帝控制器/类等从来都不是一个好主意。相反，您应该“坚持”单一责任原则并将功能分布在它所属的地方。这将使您拥有非常直观和简单的 RESTful 路由。
我同意@KrzysztofLa。当涉及到您的 API 结构时，您需要一个清晰的关注点分离。拥有一个控制器来统治它们（或上帝控制器）会在开发后期回来咬你。从一个非常具体的控制器方法返回尽可能少的数据，用户会感谢你的。

标签： rest asp.net-web-api .net-core

【解决方案1】：

我怀疑是否有一个涵盖所有情况的明确答案，但一般来说，将应用程序的每个特定部分的责任和逻辑封装在它自己的类中是一个好主意。

您提到了 CRUD（Create、Read、Update、Delete)，这是这里的中心点；顾名思义，这些操作通常遵循某种模式。如果你不能以类似的方式组织所有的控制器类，你可能能够从它们中提取公共逻辑，或者将其提取到帮助类或每个控制器可以实现的接口中。如果（何时？）您必须在以后扩展它，这反过来会使您的应用程序更加灵活且不那么混乱。

在应用的顶层使用单独的控制器也可能更容易组织较低级别的组件。例如，您可能有与每个控制器对应的单独的业务和/或存储库组件，但这些组件中的每一个都可以实现公共接口。这样，应用程序的每个部分都将包含一个单独但内部一致的“垂直切片”（例如控制器、业务和存储库）。

现在，如果您需要向应用程序添加新功能，您将拥有一个易于理解并加快开发速度的清晰模式：添加一个实现与您已有的相同通用接口的控制器，然后执行分别对于您的业务层和存储库层中的新组件也是如此。

【讨论】：