我尊敬的一位导师认为简单的 bean 是浪费时间——值对象“必须”包含一些有用的业务逻辑。
另一个人说这样的代码很难维护，并且所有业务逻辑都必须外部化。
我意识到这个问题是主观的。无论如何都要问——想从更多角度知道答案。
将数据和业务逻辑放在一起的想法是为了促进封装，并向其他对象暴露尽可能少的内部状态。这样，客户端就可以依赖接口而不是实现。请参阅“只说，别问” http://www.pragmaticprogrammer.com/articles/tell-dont-ask原则和得墨忒耳定律 http://en.wikipedia.org/wiki/Law_of_Demeter。封装使得更容易理解数据所处的状态、更容易阅读代码、更容易解耦类并且通常更容易进行单元测试。
外部化业务逻辑（通常为“服务”或“管理器”类）会产生诸如“此数据在哪里使用？”之类的问题。和“它可以处于什么状态？”更难回答。它也是一种包裹在对象中的程序性思维方式。这可能会导致贫血域模型 http://www.martinfowler.com/bliki/AnemicDomainModel.html.
外化行为并不总是坏事。例如，一个服务层 http://martinfowler.com/eaaCatalog/serviceLayer.html可能会编排域对象，但不会接管它们的状态操纵职责。或者，当您主要对可以很好地映射到输入表单的数据库进行读/写操作时，也许您根本不需要域模型 - 或者它所带来的痛苦的对象/关系映射开销。
传输对象通常用于通过提供调用层所需的最小状态信息来解耦体系结构层彼此（或与外部系统），而不暴露任何业务逻辑。
这可能很有用，例如在为视图准备信息时：只需为视图提供所需的信息，而不需要其他任何信息，以便它可以专注于how显示信息，而不是what要显示的信息。例如，TO 可能是多个数据源的聚合。
优点之一是您的视图和域对象是解耦的。在 JSP 中使用域对象会使域更难重构，并导致滥用 getter 和 setter（从而破坏封装）。
然而，也存在与大量传输对象以及通常大量重复相关的开销。我参与的一些项目最终的 TO 基本上反映了其他域对象（我认为这是一种反模式）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
