引言
分层结构是目前复杂应用系统开发时普遍使用的模式，软件中层之间的依赖关系约束是比较宽松的，并不要求上层仅可以依赖于直接下层，而是上层可以依赖于它的所有下层。
设计中我们会把各种系统的各种组件映射至不同层中，而在我所接触的一些实际项目中设计人员在映射这种组件和层间的关系时经常无意中破坏了层结构的依赖关系约束。
图表 1 典型分层结构
设计中的常见问题
问题一:数据传输对象（DTO）是否应该属于业务层？
在J2EE开发的经典著作《Core J2EE Patterns》中数据传输对象被划分在业务层模式中，那么是否数据传输对象应该被映射到业务层呢？
数据访问对象（DAO）在该著作中是被映射到整合层的，这样就会出现一个违反层依赖约束的问题，因为数据访问对象是要依赖于数据传输对象的，因此下层就会出现对上层的依赖了。
所以本人认为DTO是在各层中传输数据的，我们可以不必强求的把他们映射到上述层次中，可以把他们放置在一个公共包中。
问题二:使用POJO作业务对象的轻量级架构与上述层模型的映射
在使用POJO的轻量级结构中我们通常会使用持久化框架（如Hibernate/JPA）同时会在架构中引入仓库对象(Repository Object)，负责业务对象的获取和保存。（注意：他的功能和DAO是有区别的，仓库对象中通常只应包括业务对象的获取和保存逻辑）。
通常设计人员会把业务对象映射至业务层，而将仓库对象映射至整合层。由于仓库对象对于业务对象的依赖关系就会破坏依赖关系约束，所以这种映射方式显然不正确。
下图是作者推荐的映射方式
图表 2 轻量级架构参考模型
可以看到业务对象和仓库对象都被映射至业务层，而持久化框架被映射到了整合层。
总结
因此大家在设计过程中不要仅仅将分层结构留于形式，而要时刻注意设计是否符合这种架构模式，这样才能真正发挥这种架构模式的优势。
蔡超
JavaEE 咨询顾问
SCEA (1.2&5.0)
IBM Certified Solution Designer for OOA&D UML2
