.Net ORM框架：XLinq

jopen 9年前發布 | 15K 次閱讀 XLinq 持久層框架

吐嘈

忙活了一個多月，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
其他我說漏掉的