po什么意思 po什么意思( 二 )

对于服务层来说，它只从语义上定义：1-男性， 2-女性， 0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。
说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？
【po什么意思 po什么意思】对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。
再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO ，不应该出现与表现形式的耦合。
理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。
VO与DTO的应用上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。
在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）：

需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可
为什么是VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合
所以，对于前面的例子，你很容易理解， DTO对于“性别”来说，依然不能用“帅哥美女” ，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）
即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐

以下场景需要优先考虑VO、DTO并存：

上述场景的反面场景
因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO
这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。
如果页面出现一个“大视图” ，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装
（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的 *** 是否合适，需要在设计层面进行权衡）

DTO与DO的区别首先是概念上的区别， DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象
这就引出了两者在数据上的区别，例如UserInfo和User ，对于一个getUser *** 来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。
而在领域驱动设计中，正如第一篇系列文章所说， DO不是简单的POJO ，它具有领域业务逻辑。