数据访问层的改进以及测试DOM的发布

数据访问层的改进以及测试DOM的发布

在上一篇我们在宏观概要上对DAL层进行了封装与抽象。我们的目的主要有两个：第一，解除BLL层对DAL层的依赖，这一点我们通过定义接口做到了；第二，使我们的DAL层能够支持一切数据访问技术,如Ado.net,EF,linq To Sql，这一点我们实现的不是很完美，仍有很大的改进空间，本文将加以改进。

    在此之前我们来看一下我们最新的dom（PS:经过两天的赶工，我们的dom已经相对成熟，其中BLL层已经被我高度抽象化了，并且引进了业务上文文的概念；DAL层除了具体的技术实现尚为完成，其他方面已经相对完善了）

     DAL层的AdoDal项目和EFDAL项目，分别代表采用ado.net技术和EF技术实现数据访问层，我在这两个项目中分别定义了一个OrderDAL测试类

和一个RolesDal测试类，代码如下

 

 

 

 

   我们在BLL项目中的OrderBLL类来调用这RolesDal与OrderDAL的测试方法TestMethod()。注：我们的BLL层并没有引用DAL层，我们得到的DAL层实例，是通过工厂运用反射来实现的，至于，反射得到的OrderDAL，RolesDal是来自AdoDal项目还是EFDAL项目，完全是由我们的配置文件决定的，调用代码如下

 

  我们的UI层项目StructUI也实现了与BLL层的解耦，它并没有引用BLL，它得到的BLL层实例同样是采用工厂根据配置文件通过反射来实现的。如下

 

   从上面我们知道，UI层的页面是通过工厂创建OrderBussiness实体，然后调用Test()方法，在把结果展示在前台的文本域中。好了，现在我们来开始测试。首先，我们通过配置文件来设置对EFDAL项目中的OrderDAL和RolesDal实体进行测试，我们配置文件如下

  结果如图：
 接着我们改变我们的配置文件，代码如下 

 结果如下：

   综上，我们的框架实现了对数据访问层各类技术的支持，同时我们的成功的解除了框架中层与层的依赖（UI依赖BLL，BLL依赖DAL）。

  下面我们来看一看目前版本的数据访问层相对于上一篇的数据访问层的改进，对照我们上一篇的项目结构（下图），我们发现在的数据访问层的DAL项目被干掉了，AdoDal，EFDal与DALFactory这三个新项目被添加进来了。

　　

    先说一说，我干掉DAL，同时又添加AdoDal，EFDal的原因。在上一篇文章，我们把对不同数据访问技术的实现寄托在ADOBase<T>类型与EFBase<T>类型上面，这两个类型最终将赋值给数据访问层基类的dalActive属性，来帮助基类实现数据层接口，至于是哪一个，则由配置文件说了算，我们采用工厂读取配置文件来创建这两个类型的实例，但是这里会碰到一个技术难题：这两个类型都是范型，我们无法事先知道该类型的范型参数在实例化时会是一个什么样的类型，所以我们没办法通过反射来动态读取程序集和类名创建对应的范型实例，因此，在上一篇我采用了一个非常简陋的工厂方来创建，如下

 

    这样我们就通过条件判断语句写死了程序数据访问层所能使用的技术，在这个工厂里面除了ado.net和EF，它将不会去创建其他任何技术的访问实体。我们想要增加一种新的技术则必须重新修改工厂的代码,这样就违背了软件工程的一个原则：一个好的框架，应该是在需要什么功能的时候去扩展，而不应该是去修改以前的代码。

   另一个促使我改变程序框架的原因是因为我们目前的这种业务背景和抽象工厂模式相当的吻合。我们数据访问层采用什么技术，业务逻辑层根本就不关心，我们完全可以定义两个工厂来创建两种不同技术的实例，然后根据配置文件来决定采用哪一个工厂。但是这里我们必须设想一种情况，那就是我们的数据访问层的实体相当的多，如果我们每一个实体都用工厂来创建的话，那么配置文件肯定会很大，配置文件的节点一多起来，第一个不便于维护，第二个，不便于理解。因此，我们必须找到替代的方法，我在数据访问层定义了2个仓库类型：ADOSession与EFSession。其中ADOSession用于获取AdoDal项目中的所有数据访问实体，EFSession用于获取EFDal项目中的所有实体，代码如下

 

 

   ADOSession类型中在构造函数中需要传入了一个IDbConnection数据库连接实体，很显然这个IDbConnection会来自BLL层,这是因为我们的业务层需要有定制事务的能力，因此它必须能够得到IDbConnection来发起事务，当一个事务被发起时，所有在事务期间被创建的数据访问实体对数据库的操作必须是基于事务发起这的IDbConnection，这样的操作，才受事务的控制。因此这就要求我们的BLL层在创建DAL数据实体，有定义该实体的IDbConnection的能力,很显然，在构造函数中传入统一的IDbConnection是一个不错的选择。

   好了ADOSession，EFSession我们都有了，现在我们假设我们如果能够在BLL层拿到这样的实体，那么我们是不是就能够获得AdoDal或EFDal的所有实体呢?答案是显然的，但是这样问题又来了，我们BLL并没有引用DAL，所以这两个仓库实体什么类型BLL肯定是不知道的，BLL只认接口，因此我们必须为仓库定义接口，如下

 

   另外，我们还必须有相应的实例化机制，给BLL层的调用者提供实例化服务。因此我们想到提供两套数据访问层实例工厂来为调用者提供实例化，至于到底选择哪一套工厂，则完全由配置文件说了算。我们的两个工厂都实现了工厂接口，代码如下

 

 

 

   在BLL层的业务上下文中，我们把对应的ISessionFactory在构造函数中通过工厂读取配置文件进行实例化，代码如下

 

 

 

   配置文件参见本文DOM演示部分，在BLL层的业务上下文我们就可以通过ISessionFactory拿到ISession实体了，有了ISession实体我们就有了基于一种数据访问技术的所有数据访问层的实体了。我们BLL层可以大摇大摆的调用我们的数据访问实体操作数据库了。至此我们的数据访问层的抽象已经基本完成，剩下来的就是把数据访问层AdoDal，EFDal两个项目中的具体技术细节全部实现，这将是我后续文章的内容呢.......

总结

    本文在上一篇文章的基础上面继续优化了数据访问层，使我们的数据访问层更加的完善与成熟。一个好的应用框架总是运用中被不断的完善，我们在开发的时候，多想一想我们所用框架的局限性，我们总能找到相应的优化点，最后感谢大家的观看，本文DOM的源码请点击  这里

 

 

分类: 框架

标签: 三层架构