Business Objects - 容器还是功能？

Question

在我工作的地方,我们已经多次在这个问题上来回走动,正在寻找一个健全性检查.这是一个问题:Business Objects应该是数据容器(更像是DTO)还是应该包含可以对该对象执行某些功能的逻辑.

示例 - 获取客户对象,它可能包含一些常见属性(Name,Id等),客户对象是否还包含函数(Save,Calc等)？

一行推理说,将对象与功能(单一责任主体)分开,并将功能放在业务逻辑层或对象中.

另一条推理说,不,如果我有一个客户对象,我只想打电话给Customer.Save并完成它.如果我正在使用该对象,为什么我需要知道如何保存客户？

我们的最后两个项目已经将对象与功能分开,但是在新项目中再次提出了争论.哪个更有意义？

编辑

这些结果与我们的辩论非常相似.对一方或另一方的一票完全改变了方向.有没有人想加2美分？

编辑

尽管答案抽样很小,但似乎大多数人认为业务对象中的功能是可接受的,只要它很简单,但持久性最好放在单独的类/层中.我们试一试.感谢大家的投入......

Answer 1

对象是状态和行为在一起.如果一个对象具有明智的行为(例如,计算一个人从出生日期开始的年龄,或者一个发票的总税额),请务必添加它.仅仅是DTO的业务对象被称为"贫血领域模型".我认为这不是设计要求.

持久性是一种特殊的行为.我称之为"明智"的是商业行为.业务对象不需要知道它是持久的.我会说DAO可以将持久性与业务行为分开.我不把"保存"放在"明智"类别中.

Answer 2

业务对象可以具有业务功能.

持久性不是业务功能,而是技术实现.

长话短说:

1. 保存/更新/删除/查找等 - 远离持久层中的业务对象.
2. CalculateSalary,ApplyDiscount等是与业务相关的方法,可以是:
   1. 业务对象的方法(所以BO是实体的自包含表示)或;
   2. 实现特定功能的独立服务(因此BO更像DTO).

至于第2点.
我应该提到方法2.1倾向于使BO过于膨胀并违反SRP.而2.2引入了更多的维护复杂性.

我通常在2.1和2.2之间进行平衡,这样我就可以将与数据相关的微不足道的东西放到Business Objects中,并创建更复杂的服务(如果有超过4行代码 - 使其成为服务).

这将Business Objects的范例转换为更多的数据传输对象.

但这一切都使项目更容易开发,测试和维护.