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源码中。