Entity Framework的连接字符串纯粹就是毛线
有一种扯淡叫做毛线。
.NET的实体框架当前已经是4.1了，考虑到已经提供POCO功能，并且还支持多种数据库（这点可是Linq2Sql无法做到的），于是想试试。
不可否认，EF强大的设计能力确实很方便。但是很困惑的地方就是在Sql Server 2008下，DateTime类型在数据库中只能使用datetime2，否则运行后会报错，据说Sql Server 2005就没这个问题，当然2005中也没有这种类型。
一切都很顺利，直到有天想把现有网络版的软件转换成单机版的软件，问题就来了。
原本打算是使用DB4O来进行单机数据存储，但需要实现相应的UnitOfWork和Repository，又想到EF是支持多数据库的，换成SQLCE不就行了，都是一家人，相互认识是必然的。修改下连接字符串吧，NHiberate可不就是这样的嘛！
于是很自信地修改了下连接字符串，没想到还真出了问题。首先系统提示连接字符串有问题，折腾了一半天，原来在设计器的edmx文件中有和当前连接的数据库类型相关的信息，还必须通过XML设计器打开该文件进行修改；修改后又出现问题，提示SQL CE中不支持datatime2类型，猜到是映射的问题，又使用XML设计器打开文件手动逐一修改，同时还发现SQL CE中支持的字符串长度还不能超过4000，所有字符串超过4000的也会提示错误。
找到了原因，又想到系统需要同时支持单机版和网络版，为了提高系统的灵活性，索性复制了一个edmx，然后配置其为SQL CE类型的数据库才解决问题。没有想到EF居然是以这种方式支持多数据库的，真是BT啊。
总觉得这种解决方式有问题，搜索了一下，也找到了相应的解决办法：
http://mosesofegypt.net/post/Multiple-database-support-with-Entity-Framework.aspx，
不过还是得使用XML编辑器打开edmx文件进行手动修改，还是得添加相应的提供者类型和字段映射定义。一想到如果结构有变化我就后怕，岂不是每次都要手动重复做这番工作？这点可比NHiberate差远了。
在此终于恍然大悟，终于搞清楚EF的连接字符串为什么必须包含metadata的定义。如果要在运行时更换数据库，那么metadata的定义就必不可少，因为在其中还包含了不同数据库相关的提供者信息和字段映射信息。
真没想到EF是以这种方式实现多数据库的支持的，原来支持和自动支持是有很大差距的。
唉，真是......
不知啥时能像NHiberate一样自动支持多数据库的ORM呢？
