.Net ORM框架：XLinq

jopen 9年前

吐嘈

忙活了一个多月，XLinq总算"能用"了，BUG总算"少点"了，准备真正替代EF了，现在已经初步在自己的项目中使用了

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

必须将所有实体一次写完整，不能通过DbContext.Set<T>方法动态加载实体
NoLock，硬伤啊，貌似就算用事务然后配置成ReadUncommited也不行
EF支持的LINQ各种坑，简单说几个
1. .Where(x=>x.LastLogin==DateTime.Now.Date)，很简单很常用的代码么，但EF就是不支持
2. .Where(x=>x.Name==null)，看起来好像没问题，但EF却翻译成了where name=null，坑货
3. 左连接！不说实现左连接那郁闷的写法，郁闷的是EF不一定会给那种写法翻译成左连接
4. 第三点吐嘈完毕
删除、更新，必须先查询再进行删除和更新
性能，其实性能这个好像也没那么差，测试过查询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
其他我说漏掉的