我想知道以下API结构的最佳实践是什么:
OrderItemDepartment与OrderItemSection有一对多的关系,而OrderItemSection又与OrderItem有一对多的关系。
将api划分为控制器,每个控制器都有CRUD操作,例如:
OrderItemDepartmentsController
OrderItemSectionsController
OrderItemsController
..或者让一个控制器通过路由为OrderItems,Departments和Sections提供服务:
OrderItemsController
答案 0 :(得分:0)
我怀疑是否有一个明确的答案可以涵盖所有案例,但总的来说,将责任和逻辑分配给应用程序的每个特定部分都是一个好主意。类。
你提到CRUD( C reate, R ead, U pdate, D elete ),这是一个中心点;正如名称所示,这些操作通常遵循某种模式。如果您能够以类似的方式组织所有控制器类,则可以从它们中提取公共逻辑,可以是辅助类,也可以是每个控制器可以实现的接口。如果(何时?)你必须在以后扩展它,这将反过来使你的应用程序更灵活,更少杂乱。
在应用程序的顶层使用单独的控制器也可能更容易组织较低级别的组件。例如,您可能具有与每个控制器对应的单独的业务和/或存储库组件,但是这些组件中的每一个都可以实现公共接口。这样,您的应用程序的每个部分都将包含一个单独但内部一致的垂直切片" (例如控制器,业务和存储库)。
现在,如果您需要为应用程序添加新功能,您将拥有一个易于理解的清晰模式,并加快开发速度:添加一个控制器,该控制器实现与您已有的相同的通用接口,并执行对于业务层和存储库层中的新组件,分别相同。