数据访问组件和工厂设计模式
3.00/5 (14投票s)
一个用C#编写的通用数据访问组件实现，支持SQL、Oracle、OLEDB和ODBC数据提供程序。使用工厂设计模式在运行时实例化数据提供程序正确和特定的对象。
引言
现在几乎每个应用程序都使用关系数据库作为其后端。应用程序过去是单片的和结构化的，但随着对更多功能和易用性的需求，应用程序变得更大、更复杂且更难维护。快速开发的解决方案变得更加清晰：“抽象和代码重用”。
应用程序是分层的
- 表示层
- 业务层
- 数据访问层
数据访问层通常为以下提供通用机制和功能
- 打开和关闭数据库连接
- 处理数据库事务
- 执行SQL命令、数据读取器和数据集
改变的需求
在过去，当我开始开发时，我曾经为嵌入在应用程序中的数据提供程序编写一个特定的数据访问类。然后我习惯于将该类从一个应用程序复制到另一个应用程序。
那些都是过去的日子和坏习惯。当我需要编写一个VB.NET应用程序，其中我必须将C#数据访问类转换为VB.NET时，我开始意识到情况有多糟糕。我必须将这两个类从SQL提供程序转换为Oracle提供程序，然后再转换为OLEDB提供程序。然后事情开始变得非常糟糕和混乱：许多特定的实现共享相同的逻辑，分散在太多的代码文件和类中。
每当我需要添加一个新方法时，我都必须在太多的地方写下来。每当我需要修复一行代码时，我都必须在太多的代码文件中修复它。更不用说我总是忘记，所以我最终一遍又一遍地修复相同的错误。因此，“不良的开发者习惯”。
认识到问题并提供解决方案
有一次，我和我的一个朋友讨论工厂设计模式，我们以一个实际的工厂应用程序结束了讨论，将其应用于数据访问组件。我们意识到，如果我们需要为同一个应用程序支持两个或多个不同的数据源，那么我们只需要更改连接字符串，而无需更改数据访问层本身。那时，我意识到需要针对接口而不是特定数据提供程序的实现进行编程，那是我真正的第一次面向对象编程课
“针对接口编程，而不是针对实现编程。”
另一种面向对象编程方法
“优先使用对象组合而不是继承。”
自那以后，数据访问组件的常见功能共享相同的逻辑，但在每个数据源提供程序提供的本机连接、命令、事务和DataReader方面有所不同。那么，使用抽象类会更实用且更有益，在公共方法中提供通用逻辑，同时为每个继承的数据提供程序特定实现提供抽象方法，以实现返回本机数据源对象。设计指南
“当您需要实现不同的类具有相同的合同或协议时，请使用接口”
上面包含的源代码是用C#编写的通用数据访问组件实现，它支持SQL、Oracle、OLEDB和ODBC数据提供程序，使用工厂设计模式在运行时基于应用程序配置文件或调用方定义的数据提供程序类型来实例化特定的数据提供程序对象。有人在做功课，用好的习惯改变坏习惯。
更正？建议？评论？反馈？问题？请通过waleed_timimi@hotmail.com给我发电子邮件。
资源
- .NET 数据访问架构指南
- Microsoft .NET 数据访问应用程序块
- Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 设计模式：可重用面向对象软件的元素。 Addison-Wesley, 1995。