在前面的文章“基于MVC三层架构结合自己理念生成的四层架构”中,我提出了一个DataBase层,内容是将系统中处理数据库的部分单提出来,做成类库。现在我想就DataBase层的做一个比较详细的数据库层的架构说明,希望大家来提提意见,有兴趣也可以一起交流。首先我来给大家说一下我的设计构思,先通过一个Package Diagram来说明一下:
在上图中,整个Database被分成三个部分,Entity里面放的是是实体对象(我现在的项目用的是LINQ实体对象是生成出来的),Actity里面放的是接口,是要是数据库层能提供的接口方法,它的作用是用来规范数据库行为。Manage里面放的是需要实现的方法和暴露给上层的接口。
       简单的介绍不想大家还是不懂吧,下面我结合一个例子来说明一下吧。我先让大家看这个实例的Class Diagram
如上图所示,BookEntity中的一个实体对象,里面有三个属性,IBookActivity中的一个接口,BookManageManage中的对象,也是数据库层对外暴露的接口,在这个用了一个组合模式,对外暴露的对象包含静态对象与动态方法。我想看到这个类图大家应该明白什么意思了吧,我的BookManage可以同时包含一些动作(继承几个接口)。
       上述这么做已经在我的项目中进行了实践,根据我的项目我来有针对性的说说这个设计的设计初衷:当时发现在调用数据库层的时候,我想要完成一个数据库操作学要至少两个对象,实体对象和行为操作对象。后来我看了模式设计中针对类结构和类行为分成了两类模式,我就像是不是类结构和类行为这种区分也可以在别的地方使用呢?于是就想到了运用在数据库中。
       在使用过程中这个设计的优点和缺点:
       优点:
1、  使得数据库层对外的接口规范化,要的方法就在接口里面提供,需要多个方法的时候可以通过继承多个接口或者重载(比如一个BookManageselect就可以有两种查询的重载)方法来实现。
2、  数据库对外暴露的接口从以前的实体类和行为类两部分编程了统一的Manage类,减少了DataBase层和Model层的耦合程度。
       缺点:
1、  用于方法需要单独定于,所以会稍稍增加代码的开发量。
       以上就是我的设计想法,即使结合了例子,可能还是说的有点抽象,如果有不懂和朋友或者有建议和意见的朋友欢迎和交流,大家共同学习!