阿不

潜水

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  212 随笔 :: 0 文章 :: 3070 评论 :: 75 引用

Kooboo的一个设计初衷是跨数据库,特别是提供对轻量级数据库,文件型数据库的支持,我们总是希望给用户提供最简单,最少配置的产品。我们选择了Entity Framework来作为我们的ORM框架,隔离数据库的不同实现,以最大减少我们在跨数据库时的代码和架构复杂性。Entity Framework目前也已经提供了各种数据库的Provider,理论上是可以很容易做到跨数据库的实现。

在Kooboo 1.3中,我们将会提供对SQLite的支持。做为一个文件型的轻量级数据库,在部署方面比起其它大型数据库有非常大的优势,但同时又具备关系型数据库的完整功能,基本可以满足大部分中小网站的要求。同时我们还将支持,在SQLite中开发的网站可以完全无缝的运行在MSSQL版本的Kooboo平台上,反之亦然。接下来,我将会分享从MSSQL移值到SQLite的一些经验。

首先,我们需要将MSSQL数据库无缝转换成SQLite数据库文件,通过这个工具,我们可以很容易达到这个目的。

要实现Entity Framework的数据库隔离,我们唯一的工作就是修改EF中的三类配置信息:

CSDL:实体定义文件。这是生成实体类的根据,我们不能因为要跨数据库而修改实体代码和代码接口,因此这是不能改变的定义信息。

SSDL:数据库定义文件,这个根据不同的数据库,提供的不同的数据库元信息。

MSL:  映射配置文件,这是跨数据库重要的配置。我们需要将不同数据库的元信息,映射到统一标准的定体定义文件中,让它们以统一的接口供程序员信息。首先,在不同的数据库里面,可能会有不同的数据类型或约束名称。比如在MSSQL中,每个约束都有固定的约束名称,所有对象的映射关系都是根据这个名称来生成和映射。但是在SQLite里面,并不会保存我们指定的约束名称,而是根据自己的一些规则自动生成有规律的约束名称。这时候,需要将原来版本的关系映射配置修改为SQLite中对应生成的自动约束名称。

在SQLite中,对自增长字段有着特殊的处理,对每张表,默认都有一个自增长ID(rowid,64-bit int),而如果用户需要指定自己的自增长字段,那就必须是主键。而在Kooboo中,所有的自增长ID都不是主键,我们使用GUID做为我们的主键,因此我们需要将SQLite中的rowid,映射到实体定义文件中的自增长字段。

另外,在SQLite中,对GUID的处理也有特殊之处。默认,GUID类型的数据是以Binary存储,这时,我们只能通过ADO.NET命令参数的形式传入Guid 类型的值才能正常进行更新和查询,而不能用字符串表示的GUID进行操作。此时,我们需要在SQLite连接串中指定BinaryGuid=False,让它以字符串形式处理GUID,在减少存储空间的同时,方便我们进行操作。

在Kooboo中,还使用了ASP.NET Membership Provider。默认提供了MSSQL的实现,我们也能从网上找到SQLite的实现,但找来一看,让自己很失望。它提供了相同的API的同时,却使用着自己的数据结构,没有使用MSSQL默认的数据库结构,并且在加密算法上也有很大的区别。由于我们的数据库从MSSQL中转换过来,因此,我们希望SQLite的ASP.NET Provider也能够使用这些数据库结构,并且能够正常使用转换过来的数据。因此我们在这个实现的基础上,重新实现,让它使用MSSQL相同的数据结构和加密算法。你可以从这里得到完整的项目文件,稍后我们将会以一个单独的开源项目发布到Codeplex,同时也会包含在Kooboo源码中。

posted on 2009-12-26 15:47 阿不 阅读(...) 评论(...) 编辑 收藏