代码改变世界

走进Linq-Linq to SQL源代码赏析之Provider的初始化

2008-08-21 09:50  横刀天笑  阅读(...)  评论(... 编辑 收藏
话说Linq to SQL理论上应该支持多种数据库的,而且应该支持多种数据库,到最后却落的这个局面,是为了商业考虑还是本来技术就不成熟?不得而知。不过不管怎么说Linq to SQL的体系结构确实是支持扩展的。

 

在System.Data.Linq.Mapping这个命名空间下微软提供了一个特性:ProviderAttribute,使用强类型的DataContext或使用Xml做映射的时候,该特性可以用来指定具体的数据库提供者。如下:

[Database(“dbo.cnblogs”)]
[Provider(
typeof(SqlProvider))]
Public CnBlogDataContext : DataContext
{

}
这就表明我们的Linq to SQL是基于Sql Server数据库了,SqlProvider是实现了IProvider接口的(该接口存在于System.Data.Linq.Provider命名空间下)。

在DataContext初始化时执行的Init方法里有这样几行代码:

if (model.ProviderType == null)
    {
        
throw Error.ProviderTypeNull();
    }
    Type providerType 
= model.ProviderType;
    
if (!typeof(IProvider).IsAssignableFrom(providerType))
    {
        
throw Error.ProviderDoesNotImplementRequiredInterface(providerType, typeof(IProvider));
    }
    
this.provider = (IProvider) Activator.CreateInstance(providerType);
this.provider.Initialize(this.services, connection);

这里是根据modelProviderType创建一个IProvider的实例。Model就是一个MetaModel对象。前面两篇都提到了MetaModel有两个子类,AttributeMetaModelXmlMetaModel,看看你是用哪种方法做映射的,我们这里就用AttributeMetaModel做例子,在AttributeMetaModel的构造函数里有这样几行代码:

ProviderAttribute[] customAttributes = (ProviderAttribute[]) this.contextType.GetCustomAttributes(typeof(ProviderAttribute), true);
        
if ((customAttributes != null&& (customAttributes.Length == 1))
        {
            
this.providerType = customAttributes[0].Type;
        }
        
else
        {
            
this.providerType = typeof(SqlProvider);
        }

从DataContext类上找Provider特性,如果没有找到就默认使用SqlProvider了。创建了IProvider的实例就会调用它的Initialize方法进行初始化。Initialize方法需要两个参数IDataService和一个连接对象(DbConnection或是连接字符串)。

关于设计模式的旁白

 

桥接模式

 

看到这里也许大家都说,哦,原来实际的事情都是这个IProvider干的啊,IProvide是个接口,下面可能有SqlProvider,OracleProvider,AccessProvider,只要提供这些Provider我们就可以无限扩展数据库了。是的,设计到这一步已经可以满足多数据库的要求了,但是数据库种类的多样性只是一个方面,还有每种数据库版本的差异呢?如果我们就使用继承,就这样无限的去扩展,最后会得到一个很复杂的类层次,层次搞复杂后不仅仅难于重构,更要的是会出现很多重复,灵活性也降低了。

 

如果光使用继承,我们可能会得到这样的继承树:


这样的继承层次看起来貌似很“专业”,但是灵活性实在是不敢恭维,首先,任何一个层次的小小变动在整个继承链上都要改动,如果增加一种数据库,而这种数据有会有几种版本,各个版本之间又有些差异,那么类的数量会成倍增长。还有一个,那就是子类之间有可能造成重复,假如Sql2000Provider和Oracle9iProvider之间有重复怎么办?C#又不支持多继承,我们无法使用Martin Folwer的重构方法将子类重复的部分提升到父类。那有什么好办法呢?看看微软的设计师是怎么干的。

IProvder的初始化方法Initialize需要两个参数,其中一个就是一个IDataService接口(注意,这里是接口,那肯定有很多实现,不过由于Linq to SQL就支持一种数据库,现在也只有一种实现了,不过我们可以通过这种形式来想象和扩展,并可以学习这种理念),这个时候我们得到的是另外一种类图:

(点击看完整大图)

这里以组合的方式,组合Provider和IDataService,类的继承层次简明了很多,也可以很容易处理子类之间的重复了。

实际上这就是桥接模式,该模式的意图是抽象和实现相分离,在这里IProvider就是抽象,而IDataService这边就是实现了。通过IDataService这个接口,把SqlProvider和CommonDataService,DBProvider和DBDataService之间的依赖消除了。仔细体会一下,我们的实际项目中在哪些地方出现过这样的场景?不久以前我发了一篇博客《重构到Brdge模式》,那里描述了我实际项目中一个真实的场景。

请注意的是,实际的Linq to SQL因为只支持SQL Server,所以上面的类图描述的关系并不存在,但是我们从代码中完全可以想象的到即使要扩展也是很容易的,这就是架构的力量,即使是昨天的设计也能应付明天的变化。

 

关于Provider的初始化就介绍到这里了,在文章末尾的源代码下载里提供了IProvider类和SqlProvider类,你可以看看初始化的过程,并联系上面的图想想如何构建一个可扩展的架构。


Linq to SQL源代码下载,注意不是完整源代码,不能通过编译,我会逐渐增加源代码