各层共享使用PO的代价

    网上一大堆关于PO，POJO，DTO，VO等等对象的讨论，通常都是各持己见，公说公有理，婆说婆有理，讨论到最后也没有什么定论。今天看到一个应用的代码，发现其讲PO直接做为VO（view object）在表示层使用。只从代码上讲，这样做确实省去了跟多操作。不用重复的做对象的赋值、构造。但是会过头来看，这样无疑增加了代码的耦合性。做一个简单的假设，如果对持久层的PO进行了修改，相应的使用PO做为对应的VO（value object）业务逻辑层和使用PO最为VO（view object）的表示层都必须做相应的修改，如此的应用给代码的维护带来了很大的负担，可谓是一动则百动。
    在J2EE应用开发中，是不应该出现这中PO共享使用的方式的。实体对象不应该被跨层使用，各层维护自己的实体对象。这点看书我想大家都知道，而在实际应用中很多人都选择不遵循这一规则。（在使用hibernate时有所不同，引用：“不过由于Hibernate的强大功能，例如动态生成PO，PO的状态管理可以脱离Session，使得在应用了Hibernate的J2EE框架中，PO完全可以充当VO，因此我们下面把PO和VO合并，统称为PO。”引文：结合struts和hibernate谈J2EE架构的数据表示。）出现这总现象，我想原因只有一个就是贪图了一时的省事，在一次性应用开发中，相对的业务对象改动可能性相当的少，很多时候在做项目的时候并不会出现预料不到的改变，没有必要去管理一大堆各式各样的实体对象，这样就自然的导致了PO在各层中共享使用。可是就我目前接触到的项目基本上没有需求是如此明确的，通常需求都是在不断的改变，甚至有时到了最后发版的时候，一些客户都会提出修改需求的要求。另外就是自做需求的情况就更是如此了，这种项目的需求是不断的在变化的。为了保证项目的适应性和可扩展性，就必须保证各层之间的相对独立，尽可能降低耦合度。

非飞 2005-03-01 12:40