吐嘈
忙活了一个多月,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
- 其他我说漏掉的
使用方法
- 配置文件
这里只说最小化配置
- 建立数据库
我随便建的xlinq数据库,建了一个Users表,有两个字段,Id和Username,其中Id为自增并且是主键
- 建立实体
- 测试插入
终于到这儿了
怎么的,这跟EF的写法不是一模一样的?
运行结果:
- 测试查询
为什么要把插入放前面?因为插入了之后才有数据查询
运行结果:
- 测试更新
更新有两种方法,先查询再更新和直接更新
第一种:
运行结果:
第二种:
运行结果:
- 测试删除
删除也有查询后删除和直接删除两种,这里只说直接删除
- NOLOCK
后记
看着挺简单的基本功能,但做起来真是一把辛酸泪。计划中还有性能测试的,不过先看有多少人关注吧!
测试源码:http://files.cnblogs.com/files/wzxinchen/XlinqDemo.zip