前言
在以前的一篇文章中，為大家分享了《什么是ORM璃诀？為什么用ORM弧可？淺析ORM的使用及利弊》。那么劣欢，在目前的.NET(C#)的世界里棕诵，有哪些主流的ORM，SqlSugar凿将，Dapper校套，Entity Framework(EF)還是ServiceStack.OrmLite？或者是你還有更好的ORM推薦呢牧抵？?如果有的話笛匙，不防也一起分享給大家。
.NET(C#)主流ORM總攬
今天這篇文章分享幾款收集的目前.NET(C#)中比較流行的ORM框架犀变，比如(以下框架均為開源框架妹孙，托管于github上)：
SqlSugar?(國內(nèi))
Dos.ORM?(國內(nèi))
Chloe?(國內(nèi))
StackExchange/Dapper?(國外)
NHibernate?(國外)
ServiceStack/ServiceStack.OrmLite?(國外)
linq2db?(國外)
Massive?(國外)
PetaPoco?(國外)
SqlSugar
SqlSugar是國人開發(fā)者開發(fā)的一款基于.NET的ORM框架，是可以運行在.NET 4.+ & .NET CORE的高性能获枝、輕量級 ORM框架涕蜂，眾多.NET框架中最容易使用的數(shù)據(jù)庫訪問技術(shù)。
特點：
開源映琳、免費
國內(nèi)開發(fā)者開發(fā)机隙、維護蜘拉；
支持.NET Core；
支持主流數(shù)據(jù)庫有鹿，如：SQL Server,MySql,Oracle,Sqlite等旭旭；
維護更新及時
推薦等級:★★★★☆
PetaPoco
PetaPoco：輕量的POCO對象和數(shù)據(jù)庫映射的ORM框架。
特點：
開源葱跋、免費
推薦等級:★★★★☆
linq2db
linq2db也是一款快速持寄、輕量、類型安全的POCO對象和數(shù)據(jù)庫映射的ORM框架娱俺。從構(gòu)架上來說稍味，linq2db是對比如：Dapper、PetaPoco這個的微ORM的進一步封裝荠卷，但它不像Entity Framework那樣笨重模庐。它沒有實現(xiàn)狀態(tài)跟蹤，需要自己處理實體的狀態(tài)更改等油宜。
推薦等級:★★★★☆
Dos.ORM
Dos.ORM（原Hxj.Data）于2009年發(fā)布掂碱，2015年正式開源。在開發(fā)過程中參考了NBear與MySoft慎冤，吸取了他們的一些精華疼燥，加入新思想，同時參考EF的Lambda語法進行大量擴展蚁堤。該組件已在數(shù)百個成熟項目中應(yīng)用醉者。官方網(wǎng)站：http://ITdos.com/Dos/ORM/Inde...
特點：
開源、免費
上手簡單披诗，0學(xué)習(xí)成本湃交。使用方便，按照sql書寫習(xí)慣編寫C#.NET代碼藤巢。功能強大
高性能搞莺，接近手寫Sql
體積小（不到150kb掂咒，僅一個dll）
完美支持Sql Server(2000至最新版),MySql,Oracle,Access,Sqlite等數(shù)據(jù)庫
支持大量Lambda表達式寫法才沧，國產(chǎn)ORM支持度最高，開源中國ORM排行前三
不需要像NHibernate的XML配置绍刮，不需要像EF的各種數(shù)據(jù)庫連接驅(qū)動
遵循MIT開源協(xié)議温圆，除不允許改名，其它隨意定制修改
推薦等級:★★★☆☆
ServiceStack.OrmLite
ServiceStack.OrmLite的目標是提供一種方便孩革，無干擾岁歉，無配置的RDBMS無關(guān)類型的封裝，與SQL保持高度的契合膝蜈，展現(xiàn)直觀的API锅移，可以生成可預(yù)測的SQL熔掺。
ServiceStack.OrmLite的宗旨：Fast, Simple, Typed ORM for .NET
特點：
開源、收費（免費版只支持單個庫10張表）
推薦等級:★★★☆☆
Entity Framework (EF)
ADO.NET Entity Framework 是微軟以 ADO.NET 為基礎(chǔ)所發(fā)展出來的對象關(guān)系對應(yīng) (O/R Mapping) 解決方案非剃。該框架曾經(jīng)為.NET Framework的一部分置逻，但version 6之后從.NET Framework分離出來。
推薦等級:★★★☆☆
NHibernate
NHibernate是一個面向.NET環(huán)境的對象/關(guān)系數(shù)據(jù)庫映射工具备绽。對象/關(guān)系數(shù)據(jù)庫映射（object/relational mapping券坞，ORM）這個術(shù)語表示一種技術(shù)，用來把對象模型表示的對象映射到基于SQL的關(guān)系模型數(shù)據(jù)結(jié)構(gòu)中去肺素。
特點：
開源恨锚、免費
批量寫入
批量讀/多重查詢特性（我理解是在說Future？）
批量的集合加載
帶有l(wèi)azy="extra"的集合
集合過濾器和分頁集合
二級緩存（實際上NH的二級緩存貌似也很簡單倍靡？）
集成和擴展性
代碼自動生成猴伶，減少代碼和sql的開發(fā)量，使開發(fā)人員擺脫開sql菌瘫，ado.net和事務(wù)蜗顽，緩存等底層
推薦等級:★★★☆☆
Massive
Massive：小巧布卡，動態(tài)的微ORM框架雨让。
推薦等級:★★★☆☆
什么是ORM
ORM(Object-relational mapping)，中文翻譯為對象關(guān)系映射忿等，是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫存在的互不匹配的現(xiàn)象的技術(shù)栖忠。簡單的說，ORM是通過使用描述對象和數(shù)據(jù)庫之間映射的元數(shù)據(jù)贸街，將程序中的對象自動持久化到關(guān)系數(shù)據(jù)庫中庵寞。
為什么用ORM
在程序開發(fā)中，數(shù)據(jù)庫保存的表薛匪，字段與程序中的實體類之間是沒有關(guān)聯(lián)的捐川，在實現(xiàn)持久化時就比較不方便。那么逸尖，到底如何實現(xiàn)持久化呢古沥？一種簡單的方案是采用硬編碼方式，為每一種可能的數(shù)據(jù)庫訪問操作提供單獨的方法娇跟。這種方案存在以下不足：
1.持久化層缺乏彈性岩齿。一旦出現(xiàn)業(yè)務(wù)需求的變更，就必須修改持久化層的接口
2.持久化層同時與域模型與關(guān)系數(shù)據(jù)庫模型綁定苞俘，不管域模型還是關(guān)系數(shù)據(jù)庫模型發(fā)生變化盹沈，毒藥修改持久化曾的相關(guān)程序代碼，增加了軟件的維護難度
ORM提供了實現(xiàn)持久化層的另一種模式吃谣，它采用映射元數(shù)據(jù)來描述對象關(guān)系的映射乞封，使得ORM中間件能在任何一個應(yīng)用的業(yè)務(wù)邏輯層和數(shù)據(jù)庫層之間充當橋梁
ORM的方法論基于三個核心原則：
簡單：以最基本的形式建模數(shù)據(jù)
傳達性：數(shù)據(jù)庫結(jié)構(gòu)被任何人都能理解的語言文檔化
精確性：基于數(shù)據(jù)模型創(chuàng)建正確標準化了的結(jié)構(gòu)
本文以C#編程語言為例做裙，在傳統(tǒng)的數(shù)據(jù)讀取操作中，我們以Ado.net的方式對數(shù)據(jù)庫進行CRUD操作歌亲，使用的基本都是SQL硬編碼菇用，比如有以下數(shù)據(jù)庫查詢操作：
String sql = "SELECT ... FROM persons WHERE id = 10";
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
使用了ORM映射的C#實現(xiàn)的偽代碼：
Person p = repository.GetPerson(10);
String name = p.getFirstName();
上面的示例代碼表示我們可以從數(shù)據(jù)倉庫repository中獲取到一個實體對象，當然數(shù)據(jù)倉庫中可能包含其他的方法陷揪，你也可以定義自己的ORM實現(xiàn)惋鸥，比如：
Person p = Person.Get(10);
通常，在處理ORM映射和數(shù)據(jù)倉庫時會暴露一些過濾或者查詢方法悍缠，允許客戶端對數(shù)據(jù)集進行進一步的篩選等操作卦绣，比如代碼演示從數(shù)據(jù)庫中查詢ID=10的用戶：
Person p = Person.Get(Person.Properties.Id == 10);
優(yōu)/缺點
優(yōu)點
與傳統(tǒng)的數(shù)據(jù)庫訪問技術(shù)相比，ORM有以下優(yōu)點：
開發(fā)效率更高
數(shù)據(jù)訪問更抽象飞蚓、輕便
支持面向?qū)ο蠓庋b
缺點
降低程序的執(zhí)行效率
思維固定化
從系統(tǒng)結(jié)構(gòu)上來看,采用ORM的系統(tǒng)一般都是多層系統(tǒng)滤港，系統(tǒng)的層次多了，效率就會降低趴拧。ORM是一種完全的面向?qū)ο蟮淖龇ńρ嫦驅(qū)ο蟮淖龇ㄒ矔π阅墚a(chǎn)生一定的影響。
在我們開發(fā)系統(tǒng)時著榴，一般都有性能問題添履。性能問題主要產(chǎn)生在算法不正確和與數(shù)據(jù)庫不正確的使用上。ORM所生成的代碼一般不太可能寫出很高效的算法脑又，在數(shù)據(jù)庫應(yīng)用上更有可能會被誤用暮胧，主要體現(xiàn)在對持久對象的提取和和數(shù)據(jù)的加工處理上，如果用上了ORM,程序員很有可能將全部的數(shù)據(jù)提取到內(nèi)存對象中问麸，然后再進行過濾和加工處理往衷，這樣就容易產(chǎn)生性能問題。
總結(jié)
作為一名編程人員严卖，在ORM使用的觀念上會有不同席舍，具體取舍需根據(jù)具體的項目和場景
