分享刚出炉的ORM框架XLinq

王朝学院·作者佚名 2016-05-20

分享刚出炉的ORM框架XLinq吐嘈忙活了一个多月，XLinq总算"能用"了，BUG总算"少点"了，准备真正替代EF了，现在已经初步在自己的项目中使用了

EF这家伙，优点不少，缺点也不少，我就扯几个最让我头大的缺点（或许这里面的缺点是因为我不会用）

必须将所有实体一次写完整，不能通过DbContext.Set<T>方法动态加载实体 NoLock，硬伤啊，貌似就算用事务然后配置成ReadUncommited也不行 EF支持的LINQ各种坑，简单说几个 .Where(x=>x.LastLogin==DateTime.Now.Date)，很简单很常用的代码么，但EF就是不支持 .Where(x=>x.Name==null)，看起来好像没问题，但EF却翻译成了where name=null，坑货左连接！不说实现左连接那郁闷的写法，郁闷的是EF不一定会给那种写法翻译成左连接第三点吐嘈完毕已删除性能，其实性能这个好像也没那么差，测试过查询16万数据，近一百个字段，尼玛居然16秒就搞定了···· 暂时想不起来

分享吐嘈EF的人也不少了，我再这么就吐嘈两下完事的话有点没事找事···

所以，针对上面这些坑，我找了很多的ORM（其实好像也不多），试过alinq、dbentry.net，alinq不说，收费的，用不起···后面这个的话，当时被坑多了，就没用过了，对了，还有SOD，大神深蓝医生写的···

然而我自己也曾写过支持LINQ的ORM，但那代码渣的够可以，不过总算写过，知道些原理，其实更多的是为了锻炼，毕竟要支持LINQ的话，难度是比较大的，所以这一次又再一次自己写，功能从简单起见，主要有以下功能

支持简单的LINQ查询，多表连接查询（不支持任意形式的嵌套查询） LINQ一旦写复杂了，确实要生成高性能的SQL非常难，因为就算生成能执行的sql都比较难。我更倾向于将业务拆分，变成简单的LINQ语句能完成的功能。嵌套查询或许以后会支持，但到时候估计就是一堆坑

支持动态加载实体不需要事先在DbContext里面把实体写好，事实上什么都不写都行，主要是为了便于封装数据层，否则的话我每添加一张表都不得不去DbContext里面加一个实体

支持在LINQ中调用方法和属性，例如.Where(x=>Convert.ToBoolean(x.IsEnabled)) 上面这个写法在EF中是绝对不支持的，另外还支持Date属性访问

多数据库支持目前只支持了sqlite和sql server 2008 r2，应该说只要sql server 2008 r2支持了，那就可以部分支持其他sql server数据库了

支持自己编写翻译成sql的代码（未测试）可以自定义生成自己想的sql

支持最小化配置，最小仅需要一个连接字符串说这个我又要说java了，连hello world都没跑起来却搞了三天的配置，多麻烦！

基本兼容EF的使用方法降低学习成本

不需要查询，直接更新和删除数据调用的方式和EntityFramework Exnteded类似，这也算是EF的又一个硬伤

支持NOLock 其他我说漏掉的使用方法配置文件这里只说最小化配置