问题描述
我目前正在设计REST API，但在工作中就对象的构成进行了辩论。我们目前有一个实体框架模型，其中一些控制器包装器用作DAL。我们显然还有REST服务部分，它将基于ASP.NET Web API。这意味着我们有两组对象 - 数据层对象和服务层对象。
争论的焦点是核心业务逻辑是否需要第三组所有实际工作/处理完成的层。我的想法是，所有其他对象应该转换为业务对象，这将是常见的并用于所有核心处理。然后，该对象还将有一些方法将逻辑保存在一个公共位置（而不是简单地将所有内容放在静态帮助器方法中）。然而，其他人觉得它难以管理，并且更喜欢在业务层中以混合匹配的方式处理服务和数据对象。
你能推荐任何好的模式或标准跟着？
I am currently in the process of designing a REST API but got into a debate at work about the makeup of the objects. We currently have an Entity Framework model with some controller wrappers around them used as the DAL. We also obviously have the REST service part which will be based on ASP.NET Web API. This means we have two sets of objects - the data layer objects and the service layer objects.
The debate was around whether a third set was necessary for the core business logic layer where all the real work/processing gets done. I am of the mind that all other objects should convert into a Business Object which will be common and used in all core processing. This object will also then have methods on it to keep logic in a common place (as opposed to simply putting everything in static helper methods). However others feel its unmanageable and prefer to deal with both service and data objects in a mix-match approach in the business layer.
Can you recommend any good patterns or standards to follow?
这篇关于REST API架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！