Value对象应包含多少业务逻辑？

我尊重的一位导师认为,简单的bean浪费时间 - 值对象"必须"包含一些有用的业务逻辑.

另一个人说这样的代码难以维护,并且所有业务逻辑都必须外部化.

我意识到这个问题是主观的.无论如何要求 - 想从更多角度了解答案.

将数据和业务逻辑放在一起的想法是促进封装,并尽可能少地向其他对象公开内部状态.这样,客户端可以依赖于接口而不是实现.请参阅"告诉,不要问"原则和得墨忒耳定律.封装使得更容易理解数据可以处于的状态,更容易读取代码,更容易解耦类,并且通常更容易进行单元测试.

外部化业务逻辑(通常是"服务"或"管理器"类)会产生诸如"这些数据在何处使用？"之类的问题.和"它可以在哪些状态？" 更难回答.它也是一种程序化的思维方式,包裹在一个物体中.这可能导致贫血领域模型.

外化行为并不总是坏事.例如,服务层可能会编排域对象,但不会接管其状态操作职责.或者,当您主要对可以很好地映射到输入表单的数据库进行读/写操作时,您可能根本不需要域模型 - 或者它需要的痛苦的对象/关系映射开销.

传输对象通常用于通过提供调用层所需的最小状态信息来将架构层彼此(或从外部系统)分离,而不暴露任何业务逻辑.

这可能很有用,例如在为视图准备信息时:只需为视图提供所需的信息,而不是其他内容,以便它可以专注于如何显示信息,而不是显示哪些信息.例如,TO可能是多个数据源的聚合.

一个优点是您的视图和域对象是分离的.在JSP中使用域对象可能会使您的域更难以重构并促使不加选择地使用getter和setter(从而破坏封装).

但是,也存在与拥有大量传输对象相关的开销,并且通常也会有很多重复.我一直在使用TO的一些项目基本上反映了其他域对象(我认为是反模式).

这取决于.

哎呀,我只是脱口而出陈词滥调？

要求设计对象的基本问题是:管理对象数据的逻辑在被其他对象使用/使用时是否会不同或相同？

如果不同的使用领域需要不同的逻辑,则将其外部化.如果对象移动到哪里是相同的,请将其与课程放在一起.

您最好将它们称为传输对象或数据传输对象(DTO).

早先,这个相同的j2ee模式被称为"价值对象",但他们更改了名称,因为它与此相混淆

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

为了回答你的问题,我只会将最小的逻辑放在我的DTO中,这是显示原因所需的逻辑.

更好的是,如果我们谈论基于数据库的Web应用程序,我将超越核心j2ee模式,并使用Hibernate或Java Persistence API创建支持延迟加载关系的域模型,并在视图中使用它.

请参阅视图中的打开会话.

通过这种方式,您无需编写一组DTO,并且可以在视图/控制器等中使用所有业务逻辑.