Value 对象应包含多少业务逻辑？[已关闭]

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

将业务逻辑外部化（通常分为“服务”或“管理器”类）使得诸如“这些数据在哪里使用？”和“它可以处于什么状态？”这样的问题更难回答。它也是一种程序性的思维方式，包裹在一个物体中。这可能导致域模型衰弱。

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

传输对象通常通过提供调用层所需的最少状态信息来使体系结构层彼此分离（或与外部系统），而无需公开任何业务逻辑。

这可能很有用，例如在为视图准备信息时：只需为视图提供所需的信息，而不是其他信息，以便它可以专注于如何显示信息，而不是显示什么信息。例如，TO 可能是多个数据源的聚合。

一个优点是视图和域对象是分离的。在 JSP 中使用域对象会使域更难重构，并促进不加选择地使用 getter 和 setter（从而破坏封装）。

但是，也存在与拥有大量传输对象相关的开销，并且通常也存在大量重复。我参与过的一些项目最终都使用了TO，它们基本上反映了其他领域对象（我认为这是一种反模式）。

最好将它们称为传输对象或数据传输对象 （DTO）。

早些时候，这个相同的j2ee模式被称为“Value object”，但他们更改了名称，因为它与此混淆了。

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

为了回答您的问题，我只将最小的逻辑放在我的DTO中，这是出于显示原因所必需的逻辑。

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

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

通过这种方式，您不必对一组DTO进行编程，并且您可以在视图/控制器等中使用所有业务逻辑。