设计模式系列一——数据库常用模式(2009-12-31)

最近在研究架构的时候，一直有一个问题围绕着我，就是这些架构虽然好，但并不是有了好的架构软件开发质量就会提高，软件就会美观更贴近艺术。我感觉，要想开发出好的软件，架构、在架构之中层（我喜欢叫容器，我感觉先简单理解成package也可以）内部设计以及相关通用模块的积累都是软件开发重中之重，对于一个软件设计来讲，三个方面缺一不可，因为三个方面是相辅相成。我开的这个系列就是想简单说说我在相关设计上的一些思路，当然还希望高人路过时多多指点，让小弟多多学习，这里先谢过了。
我记得在前面的一篇文章中，我曾经写过，当时要给MVC中的M层设计一个架构。本篇文章主要是针对软件开发中的数据库层的设计进行的思考。文章在有些思想上和前面的文章有些许相同，不过更正和重新设计了一下新的思路，下面的说明中我将尽量使用UML图来进行说明，相信应该比看代码更清楚，而且写代码的话内容就太多了。
首先我明确一下自己的设计思路和设计目的：
一、希望上层直接使用对象数据。
二、下层和hibernate或jdbc能兼容。
首先我来秀一下主要思路的设计图：

上图中我们看到，整个软件项目是在一个com包中，里面主要是我们这次将的数据库层设计即DataBaseTier包。其结构已经一目了然了，我们以Hibernate为例，三个包的依赖关系为：EntityClass依赖EntityClassManagement，EntityClassManagement依赖HibernateManagement包。三个包我们都可以对该包进行“自测管理”，“信息监控”、“出入口统一化”等机制设置（“自测管理”，“信息监控”、“出入口统一化”等机制设置等都是软件设计的基本功，但不是本篇文章的重点）。这样做在QA上、入后维护上、代码美观方面都有良好的帮助。
我进一步说明，EntityClass包主要是放关系数据库中表的实体类，其内部结构如下：

整个包中有一个抽象的超类EntityClass，包的内部分为几个小包，分包是依据数据架构中主题域的设计而定的。多少个主题域为多少个包，每个主题域又都有一个超类SubjectEntityName继承EntityClass类，每个主题域中的每一个类对应着主题域中的一个实体对象。上述说的有一点点抽象，我给大家一个实现，看看就明白了。

上图显示的是一个主题域样例（图书馆管理系统的主题域片段），我们看到这个继承体系中，最后能被实例化的只有User，也就是说抽象类EntityClass和SubjectEntityName都是不能实例化的，我们可以藉由SubjectEntityName来确定实体对象的所在主题域。是不是很方便软件开发工程师理解其设计并进行开发呢。这个很明显使用了抽象工厂模式。
我们在回来看DataBaseTier这个图：

EntityClassManagement包中是Interfaces（接口）包和Implements（执行操作）包，这里主要是体现了（ISP）接口分离原则。最后是根据项目的需要所要使用的JDCBManagement包或者HibernateManagement包，我们以HibernateManagement包为例，其主要作用就是管理数据库的操作。
当然我上面讲了很多都是有一个前提条件的，就是数据都是来源我们自己的数据库，如果有其他系统的数据来源怎么办呢？我们看到，在设计中还有一个OtherSystemData包，执行数据操作的时候，这个包就起到了一个外系统数据交互的作用了。我在这部分的设计中使用比较多的模式是：（Factory）工厂模式、（Abstract Factory）抽象工厂模式、（Adapter）适配器模式、（Composite）组合模式。
 罗嗦了这个朋友也烦了吧，现在就介绍完了，喜欢的朋友可以试试哦。这个设计对于小系统来说效果一般，并且在开发的时候也会有些感到设计复杂，但是对于有主题域这样的大型项目而言还是不错的哦。