前段时间提到使用DAAB模块引用到自己的系统中遇到的困惑：http://dragonpro.cnblogs.com/archive/2005/10/20/258486.html
后来经过我的反复思索和试验，找到了一种折中的方式，既尽量减少了重复代码屏蔽了数据库的异构问题，又可以较合理体现分层体系。现在抽空把这个架构分享出来，给大家多多少少一点参考，也希望多批评指正。
目的：
按照这三方面来考虑，参考了这么几种方式：
1. 单独建立DAL接口，在数据提供层分别实现这些接口，在应用层调用这些接口方法，另外还要工厂方法来实时装配这些实现，这适合在一些较小型的应用，比如.NET Petshop。优点是规范，性能好，缺点是维护较麻烦。
2. 在应用层提供抽象类的抽象方法，然后分别在数据层实现这些方法，在抽象类里使用Singleton模式使用静态方式加载实现层，这可以是一些较大型的应用，比如CommunityServer。优点是规范，性能好，缺点是代码量大，迁移维护较麻烦。
3. 还有就是微软提供的Entriprise Library DAAB模块，用次模块声称可以屏蔽调数据库的异构性。优点是可以尽量减少代码量，缺点是并不能完全屏蔽数据库异构，并没有声称的那么完美，比如Oracle多数据集的返回和其他一些特性，支持的并不好。
4. 用Hibernate类似的对象持久化技术。优点是可以可以规范对象和方便的持久层配置，缺点是不太灵活，也不适合在已有的系统中实现。
上面几种方式都是比较流行的做法，但有缺点和优点并存，作为追求完美的我们，想想能不能做到既可以很好的规范和性能又可以尽量减少代码维护的成本呢，我试着这么做了一下，其实就是折中了一下这几种方案。
如图，仍然基于上面的分层方法，只是在抽象类里使用了DAAB模块，这样大部分返回单数据集或执行单条语句或执行单独的存储过程的方法都可以在这个抽象模块里使用DAAB模块实现，只有遇到DAAB模块没法解决的时候再在实现层实现。这种情况适合需要同时支持多数据库的系统，并且数据库的数据结构和存储过程名和参数要一致，可以在做完一个数据库后再迁移到另外的数据库系统，迁移工具和方法可以参考这些文章：
http://dragonpro.cnblogs.com/category/27102.html
示例代码：
抽象类
帮助器类
实现层很简单
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。