简介

DotNetNuke（以下简称DNN）的最终目的是创建一个门户的框架平台，这个平台可以为开发者增添模块搭建应用程序提供坚实的可靠的支持。应用程序的一个关键的功能就是数据存取。.NET Framework提供了多种数据存取的方法，从架构的角度来看从这么多方法中选出适合自己的需求的最佳的解决方案很难。本白皮书将尝试着在DNN应用程序的实现中提供最合适的数据存取策略。

策略

在很多资料中有各种关于.NET Framework数据存取方法的介绍，然而他们大多脱离了现实的实际应用。虽然大家常常讨论的是这些方法的优点和缺点，但是现在仍有很多开发者不知道如何选择自己的最佳策略。事实上每种方法都有适合它的不同的用例，理论上这是对的，这也是难以选择的原因，然而在实践中，每一个开发者都在寻找一个适合所有企业应用的存取策略。

一致的数据存取策略有许多好处，有了统一定义好的数据存取策略，开发者就无需浪费时间来为每个任务选择数据存取方法，这种模式提高了代码的维护性，在所有的应用程序范围内实现了一致性。通过数据存取组件的集中处理使得数据存取策略风险降低了，也使得代码的完整性增强了。

一致的兼容的数据存取策略的概念的确跟每个需求应用其最佳的数据存取策略相悖。为每个应用程序选择相应的最佳的数据存取策略能够获得最好的性能（假定你能够从所有的用例中筛选出最适合的方案）。可是这样可能导致团队在开发实践中难以协调的合作。

DotNetNuke抛弃了众所周知的传统的80/20原则，它把精力集中在提供一致的兼容的数据存取策略，这个策略理想的目标是把80%的精力放在应用程序用例上，剩下的20%用来考虑跟用其他的数据存取方法相比是否性能要求是必须的，同时也采用了上面所述的策略。

需求

DNN的一个重要的需求就是要提供一个能够支持多种数据存储应用程序的实现方法。

      由于对外部数据存储通信的灵活性和性能的要求，我们选择放弃一般的数据存取方法而打造一个新的应用，这个新的应用主要利用了数据库本地化特征集（也就是用.NET管理提供者、所有的SQL语言、存储过程等等）。在选择特殊的数据库访问类时我们做了权衡，我们需要为我们想要支持的每个数据库平台写一个特殊的数据访问层，因此应用程序也就包含了更多的代码。数据访问层共享了大量共同的代码，每一个访问层都明确的处理了特殊数据库应用。

      为了简便的应用数据库访问类我们选择了提供者模式（也就是GOF描述的工厂设计模式），这种模式是通过反射的在应用程序运行时动态的加载正确的（适合的）数据访问对象。工厂是这样实现的：先创建一个抽象类，这个类声明了一个方法，这个方法是每一个数据访问类都必须继承实现的。对每一个我们支持的数据库，我们创建了一个具体的实现类，这个类实现了抽象类或“协议”中定义的各种数据库操作的代码。为了支持在运行时动态加载具体的操作类，我们在工厂里实现了一个Instance()方法，这个方法依赖于提供者类从配置文件读取并反射过来的值来决定需要加载哪个程序集。由于反射在应用程序性能方面非常耗费资源，我们把数据库提供者类的构造器储存到缓存里。

       那么为什么用抽象类而不用接口呢？这是因为接口是（不可变的）静态的，而且因此接口也不能将其自身复制（翻译）。由于接口不支持实现方法继续继承，所以这些类的模式不采用接口。为接口增加一个方法跟为基类增加一个抽象方式是等效的；任何类实现了接口它也就终止了，因为这些类不能再实现新的方法（确切的说应该是接口定义以外的方法接口无法使用）。

      下面的图表展示了业务逻辑、工厂以及数据库存取类是如何相互联系的。这个解决方案的关键优势是只要数据访问类实现了DataProvider抽象类的方法，数据库访问类就能够在业务逻辑类之后编译。这就意味着在我们想要创建另一个数据库的实现方法时我们无需改变业务逻辑层（或用户界面层），创建另一个实现方法的步骤是：

1、  为新的数据库创建数据库访问类，这些类实现了DataProvider的抽象类。

2、  将这些类类编译成一个程序集。

3、  测试并配置这个新的数据访问程序集到正在运行的服务器。

4、  修改配置文件，来指定新的数据库访问类。

5、  无需对业务逻辑组件进行任何改变也无需重新编译它。