分享剛出爐的ORM框架XLinq

吐嘈

忙活了一個多月，XLinq總算"能用"了，BUG總算"少點"了，準備真正替代EF了，現在已經初步在自己的項目中使用了

EF這家伙，優點不少，缺點也不少，我就扯幾個最讓我頭大的缺點（或許這里面的缺點是因為我不會用）

1. 必須將所有實體一次寫完整，不能通過DbContext.Set<T>方法動態加載實體
2. NoLock，硬傷啊，貌似就算用事務然后配置成ReadUncommited也不行
3. EF支持的LINQ各種坑，簡單說幾個
   1. .Where(x=>x.LastLogin==DateTime.Now.Date)，很簡單很常用的代碼么，但EF就是不支持
   2. .Where(x=>x.Name==null)，看起來好像沒問題，但EF卻翻譯成了where name=null，坑貨
   3. 左連接！不說實現左連接那郁悶的寫法，郁悶的是EF不一定會給那種寫法翻譯成左連接
   4. 第三點吐嘈完畢
4. 已刪除
5. 性能，其實性能這個好像也沒那么差，測試過查詢16萬數據，近一百個字段，尼瑪居然16秒就搞定了····
6. 暫時想不起來

分享

吐嘈EF的人也不少了，我再這么就吐嘈兩下完事的話有點沒事找事···

所以，針對上面這些坑，我找了很多的ORM（其實好像也不多），試過alinq、dbentry.net，alinq不說，收費的，用不起···后面這個的話，當時被坑多了，就沒用過了，對了，還有SOD，大神深藍醫生寫的···

然而我自己也曾寫過支持LINQ的ORM，但那代碼渣的夠可以，不過總算寫過，知道些原理，其實更多的是為了鍛煉，畢竟要支持LINQ的話，難度是比較大的，所以這一次又再一次自己寫，功能從簡單起見，主要有以下功能

1. 支持簡單的LINQ查詢，多表連接查詢（不支持任意形式的嵌套查詢）

   LINQ一旦寫復雜了，確實要生成高性能的SQL非常難，因為就算生成能執行的sql都比較難。我更傾向于將業務拆分，變成簡單的LINQ語句能完成的功能。嵌套查詢或許以后會支持，但到時候估計就是一堆坑

2. 支持動態加載實體

   不需要事先在DbContext里面把實體寫好，事實上什么都不寫都行，主要是為了便于封裝數據層，否則的話我每添加一張表都不得不去DbContext里面加一個實體

3. 支持在LINQ中調用方法和屬性，例如.Where(x=>Convert.ToBoolean(x.IsEnabled))

   上面這個寫法在EF中是絕對不支持的，另外還支持Date屬性訪問

4. 多數據庫支持

   目前只支持了sqlite和sql server 2008 r2，應該說只要sql server 2008 r2支持了，那就可以部分支持其他sql server數據庫了

5. 支持自己編寫翻譯成sql的代碼（未測試）

   可以自定義生成自己想的sql

6. 支持最小化配置，最小僅需要一個連接字符串

   說這個我又要說java了，連hello world都沒跑起來卻搞了三天的配置，多麻煩！

7. 基本兼容EF的使用方法

   降低學習成本

8. 不需要查詢，直接更新和刪除數據

   調用的方式和EntityFramework Exnteded類似，這也算是EF的又一個硬傷

9. 支持NOLock
10. 其他我說漏掉的

使用方法

1. 配置文件

   這里只說最小化配置

   

2. 建立數據庫

   我隨便建的xlinq數據庫，建了一個Users表，有兩個字段，Id和Username，其中Id為自增并且是主鍵

3. 建立實體

   

   

4. 測試插入

   終于到這兒了

   

   怎么的，這跟EF的寫法不是一模一樣的？

   運行結果：

   

   

5. 測試查詢

   為什么要把插入放前面？因為插入了之后才有數據查詢

   

   運行結果：

   

6. 測試更新

   更新有兩種方法，先查詢再更新和直接更新

   第一種：

   

   運行結果：

   

   第二種：

   

   運行結果：

   

7. 測試刪除

   刪除也有查詢后刪除和直接刪除兩種，這里只說直接刪除

   

8. NOLOCK

   

   

后記

看著挺簡單的基本功能，但做起來真是一把辛酸淚。計劃中還有性能測試的，不過先看有多少人關注吧！

如果想討論與此相關技術或者索取源碼，請進QQ群74522853，答案XLinq

測試源碼：http://files.VEVb.com/files/wzxinchen/XlinqDemo.zip