梁逸晨的IT专栏 草如茵，松如盖，风为裳，水为佩。

  本文讲述在“中等信任”环境的IIS下面创建一个简单但是实用的多数据库兼容方案。有时候我们换一下思路，可以得到更实用、间接的办法。 强调两个要点：

1. 中等信任环境
2. 多数据库兼容 

二者缺一不可。“多数据库兼容”中的“多数据库”是指 除了SQLServer和ACCESS之外，至少包含有MySQL、SQLite、DB2、FireBird中的一款到多款非微软公司开发的关系型数据库。

 

如果您能够保证自己的程序今后永远都能够运行在“完全信任”等级的IIS中，本文不适合您，您完全可以去使用现成的第三方DBHelper和DbProviderFactories.GetFactory，它们更成熟稳定

 

记得我小学五年级的时候，语文老师（同时也是我班主任）经常布置一些生词给我们造句，就拿“简洁”这个词来说，很难琢磨出一句话来交作业，没办法，我承认我智商比较低。但是我总感觉应该有一种万能的方法，可以快速过关，以不变应万变的。 所以，当时我花了几天时间来研究了一下诸子百家和四库全书，最终得出这个万能方案：

 

public string Print(string word)
{
    Console.WriteLine("用\"{0}\"这个词来造句简直易如反掌。",word);
}

 

 

怎么样？完成任务！这下无论她布置什么词语下来，我都可以瞬间作答。

作业交上去，一天又一天过去了，她既不打勾，也不打叉。终于有一天，她拿着我的几篇作业，在班会上面宣读，全班哄堂而笑，他们笑什么我不知道，因为我照规章完成任务了，但是我也认识到，再这样下去是行不通了。

 

唉，看来她还是喜欢我们老老实实，只要谁有了点不规矩的行为，即使在道理上没有做错，她也要打压赶尽杀绝，唉，其实今天都还有这种事情，看看周围，算了不说了。

 

DbProviderFactories.GetFactory 是一个很方便的功能，能够动态获取我们需要的数据库连接对象，但是它有一个遗憾： 它的内部实现存在比较复杂的反射机制，导致用这种办法不能在中等信任权限的IIS上面创建Sqlserver和OLEDB之外的数据库连接对象，例如：MySql、SQLite， 典型的例子就是Godaddy的空间。

 

MySql自家的 Connector 组件虽然提供了DbProviderFactory，但是依然因为权限问题无法运行。

SQLite 则分为两种情况：

• 普遍用得最多的一种是.net作为外壳，内部是WIN32的，这种DLL就不要妄想在IIS上面运行了，除非是自己的服务器。
• 另一种方案是纯.Net编写的 CSharpSQLite , 它的情况和MySql的Connector一样，自身提供的 DbProviderFactory 只能够运行于完整信任模式。 中等信任的Godaddy免谈。

 

好了，下面进入解决方案：

我们知道,所有的Connection类都最终继承于 IDbConnection 接口 ，为此我们可以先建立一个IDbConnection 创建方法：

 

    public interface IDbFactory
    {
        IDbConnection CreateConnection();
    }

 

接下来的问题，怎么实现具体类呢，直接返回 new SqlConnection() ? 不，那是相当愚蠢的做法。通过泛型调用，我们可以这样子实现：

 

        public IDbConnection  CreateConnection<C>() where C : IDbConnection, new()
        {
            var temp = new C();
            temp.ConnectionString = “server=xxx,id=xxx,password=xxx”;
            return temp;
        }

 

 

好了，现在行为逻辑已经有了，但是怎么运用在实际程序里面呢， 如果我们直接使用：

 

var conn = CreateConnection<MySqlConnection>()

 

 

这简直就是自欺欺人。还不如直接 var conn = new MySqlConnection() 算了。 现在我们急需一个封装，避免在客户端中使用实际的类型参数。我们先这样子实现：

 

   internal sealed class FactoryBuilder<C> : IDbFactory
        where C : IDbConnection, new()
    {
        string _connectionString; 

        public FactoryBuilder(string connectionString)
        {
_connectionString = connectionString;
        }

        public IDbConnection CreateConnection()
        {
            var temp = new C();
            temp.ConnectionString = _connectionString;
            return temp;
        }
    }

 

这里说一句题外话，在一个framework的设计和编码中，合理的使用 internal 和 sealed 来修饰一个class， 可以在“对自己开放”、“对客户封闭”这个矛盾之间达到合适的平衡。客户端没有必要调用的类，就尽量封闭，这样便越是稳定。

 

然后我们再建立一个全局的静态变量：

 

    public class Config
    {
       public  static readonly IDbFactory DefaultFactory  = new FactoryBuilder< OleDbConnection>(connectionString);
    }

 

在客户端中我们这样引用：

 

var conn = Config.DefaultFactory.CreateConnection();

 

 

大功告成！客户端中已经不存在类型参数了，放心用就是。 

细心的读者此时可能还会发现代码中存在一个致命弱点：如果要把OleDbConnection换成SqlConnection怎么办？还是需要配置文件支持才可以修改的，还是需要web.config。

这时候我们又回到了问题的开始：如果使用web.config，只有两种办法:

•  一是使用 Eval结合web.config中的字符串来制造动态代码，但是免谈了，那还不如一开始就 var conn = Eval(“new SqlConnection()”)。 或者用反射，但是反射的致命弱点：中等信任环境拒绝运行（ACCESS和SQLServer可以，别的数据库不行，也没有保证）。所以，反射动态代码都是行不通的。
•  二是 switch判断, 先在代码中硬编码：

              string t = ConfigurationManager.AppSetting["dbtype"];
  
              IDbFactory fac;
  string connectionString = "server=xxx;uid=xxx;password=xxx";
  
              switch (t)
              {
                  case "oledb": 
                      fac = new FactoryBuilder< OleDbConnection>(connectionString) ();
  
                      break;
  
                  case "sqlserver":
  
                      fac = new FactoryBuilder< SqlConnection>(connectionString) ();
                      break;
  
                  case "mysql":
  
                      conn = new FactoryBuilder< MySqlConnection>(connectionString) ();
                      break;
  
                      //.........其它雷同，省略........
              }

   

•  

 

反正来来去取也就那么几个数据库，你把它们都写进去之后，就不存在“需求扩充”的问题了，这个办法看似解决了实际问题，但是会在每一次对象建立的时候都要判断一次，而我们的系统，也许一但定型下来，就再也不需要修改数据库类型了。 而运行时还需要作这样的判断是相当愚蠢的。所以，这个办法也免谈了。

 

一要避免无效计算，二要避免中等信任环境拒绝运行。再想一想，一定有办法解决的，就像10多年前一样：用“简洁”这个词来造句简直易如反掌。

 

“简洁”？灵光一闪：是不是尽量化简会更好？

 

我们是不是可以直接用cs文件来作为配置文件？ PHP、JAVASCRIPT、ASP 不就是用它们自身的代码文件来直接些配置的吗？ 一切化简回去，不是很好？凭什么写在多余的XML文件中？不用XML就犯法？还是会被抓去挖煤？  

 

ASP中可以通过 <!--# include=”xxx.asp” --> , javascript可以通过 script src=”xxx.js”， PHP中应该是什么我不知道，但是我配置wordpress的时候就是看它这么做的。

 

C#不存在这样的或者类似的导入办法，难道还要建立一个工厂或者什么抽象类、接口、再来一道多态，接这再封装隐藏一个泛型参数？为了一个Connection类再这样搞下去的话，和我那篇《回忆孔先生》还有何区别？再想想，有办法的。

 

partial class !

 

 

不说废话，直接改：

 

    //这一段封装为DLL文件
    public partial class Config
    {
        static IDbFactory _defaultFactory;

        static void SetDefault<C>(string connectionString) where C : IDbConnection, new()
        {
            _defaultFactory = new FactoryBuilder<C>(connectionString);
        }

        public static IDbFactory DefaultFactory
        {
            get
            {
                return _defaultFactory; //不需要null判断，静态构造函数会保证它一定经过初始化
            }
        }
    }


    //这一段分布类作为一个单独文件（并且是这个文件的全部内容），放到app_code目录中
    public partial class Config
    { 
        static Config()
        {
            SetDefault<OleDbConnection>("Server=xxx;uid=xxx;password=xxx");
        }
    }

 

 

这时候我们可以在客户端里面这样子调用了：

 

    class Program
    {
        static void Main(string[] args)
        {
            var conn = Config.DefaultFactory.CreateConnection();

            conn.Open();

            //该做什么做什么了
            conn.Close();
        }
    }

 

 

怎么样？ 无反射、不存在多余判断、Godaddy顺利运行。 有了最关键的Connection，天得一以清，地得一以宁，接下来的Command、Datareader、Datatable、DataSet ……不用愁了。

其实不止Godaddy，很多国外空间都是中等信任的，而且出于“做好自己”的原则，我们应该保证自己的程序尽最大程度的兼容，而不是到时候埋怨“XXX权限不够，不关我的事”---这是推脱。我们不能保证别人会怎么样，只有做好自己。

为什么我要反复强调基于“国外空间”，你们懂的。

 

后话：写到一半的时候，想给一段代码加颜色，结果IE8假死，幸好最后是恢复了，代码段外面的内容换颜色没问题。

 

完整示例代码下载