Abstract Factory:那个DBConnection DBCommand就是抽象的产品基类。而SqlConnection SqlCommand 和MysqlConnection MysqlCommand就是 具体产品。而Sql（代表Sql server），Mysql则分别是 两种产品系列。
Builder：一步一步创建一个复杂的对象,具体怎么创建的，用户其实并不知情。用户只需要提供 DBConnection,DBCommand这2大核心对象，然后调用DBCommand这个对象的Execute（具体可以有多种执行方式，可以ExecuteScalar，可以是ExecuteReader，也可以是ExecuteNonQuery）。
Command：说到执行的多种方式，又应该应用了 命令 模式。因为，每次查询动作，被包装成一个命令。我们本来是需要直接向数据库发命令（相当于直接找到厨师，叫他做菜），现在是向DBCommand这个抽象的命令对象中，发送消息（消息就是sql语句，也就是命令的具体内容，相当于点菜，要用到的菜单——现在不是直接命令厨师，而是把命令写在纸上，找服务员——这是一个间接层）。
这里想比较一下，.net的实现与Java的Jdbc的实现。.net的实现，我们通常使用具体的命令对象，SqlCommand，而jdbc的实现，一般是使用Statement和PreparedStatement两个接口。——当然，.net使用DBCommand抽象基类也是没问题的，几乎不算啥区别了。
有一点的区别是，jdbc的Statement和PreparedStatement两个接口的实现类，都必须是由 Connection对象创建，也就是说，你没办法去new一个具体的 命令对象 。而很显然，.net是可以 new SqlCommand()，然后把SqlConnection和CommandText等对象挂载到SqlCommand对象的属性上去的。
这样实现的结果，就是Jdbc的实现更简单，没有办法细致控制每个子类对象（没有继承就没有扩展）。当然，有时候可能可以省略这种扩展性（比如，不需要设置参数啊，执行存储过程啊这些复杂的功能，那我简单的用接口的方法，就已经足够）。引出下一个设计模式。
Facade：由于Java的Jdbc几乎都是基于接口的操作，因此它封装的更彻底。你只需要按照jdbc规定的流程去走完，对客户暴露的就是Connection，sql语句（就是命令模式中包装的消息），以及返回值。甚至连Command，用户都是摸不到的（因为是抽象的，没有 构造器 。。需要这样调用Connection.createStatement()得到）。而.net则更倾向于对用户开放些权限。比如，可以定制Command的属性，它可以是简单的sql，也可以是 存储过程的调用。（调用存储过程，就需要In/Out参数，子类需要扩展）。总而言之，言而总之，两者都是包装得非常好，用户接触到的东西都不多。（我们可以对比一下，如果直接用命令行访问数据库，是不是很麻烦，要一步步连接，再查询，再拿返回值）。
