用于.NET Core的ORM是怎樣的

今天就跟大家聊聊有關用于.NET Core的ORM是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

盡管EF Core正努力提供視圖和存儲過程等基本數據庫特性，但是開發人員也在尋求能滿足他們數據訪問需求的ORM工具。下面列出一些相對廣為使用的ORM。

LLBLGen Pro Runtime Framework

LLBLGen Pro Runtime Framework是一種“可選”的ORM，它是與LLBLGen實體建模工具一并使用的。這里稱其為“可選的”，是因為它也能和Entity Framework等其它ORM一起工作。

類似于Entity Framework，LLBLGen Pro Runtime Framework也是一種OOP風格的完備ORM（Full ORM）。但是它在幾個方面上有所差異，首先是它更側重于性能。盡管EF Core的性能顯著高于經典的Entity Framework，但是兩者依然明顯地低于其它的ORM。LLBLGen Pro的作者Frans Bouma發起了一個性能比賽，意在比較各種.NET數據訪問和ORM實現的速度。

LLBLGen Pro Runtime Framework也不同于EF/EF Core，它并非綁定于上下文（Context）的。每個實體無需維持一個打開的上下文，就可以追蹤自身的改變，并在內存中操作對象圖。該特性無疑會受到DBA的歡迎，因為無需維持打開的上下文，意味著不需要維持一個打開的數據庫連接，否則需要操作數據庫的連接池。

與大多數用于.NET Core的ORM一樣，在LLBLGen Pro Runtime Framework的Core版本上存在一些限制。但這些限制主要局限于.NET Core本身的缺失特性。例如，TransactionScope目前尚不被SqlClient支持、很少一部分對象是可二進制序列化等。

Dapper

另一種是廣為人知的微ORM（Micro-ORM）產品Dapper。Dapper常被認為是最快的ORM，幾乎總是保持著.NET ORM基準測試的頭名位置。

通常使用Dapper實現對原始SQL的調用并物化查詢結果，因此它在.NET和.NET Core上的工作情況基本相同。Dapper不同于完備ORM，它并不提供任何SQL生成功能。雖然許多開發人員并不相信由ORM生成的SQL，但這還是會令Dapper在使用上要比其它ORM產品更為繁瑣。

LINQ to DB

LINQ to DB稱自己是“超出Dapper、Massive、PetaPoco等微ORM產品一步之遙”。它不具備一些在Entity Framework中使用會引發性能問題的特性，例如更改追蹤。

LINQ to DB中的Join操作有些不同。在EF中，任何需要執行“Join”操作之處，事實上是作為子對象或集合（Collection）對待的。所生成的SQL自然會使用Join操作，但是當結果集被物化為對象后，SQL語句的執行就不再依賴于Join操作了。

LINQ to DB實際執行Join操作，具體實現為“Left Join”和“Inner Join”操作。如果使用EF解釋LINQ，那么生成語句在語法雖然略顯奇特，但更好地匹配了數據庫的實際工作情況。

DevExpress XPO

eXpressPersistent Objects（XPO）是一種商業產品。Reddit用戶“-GrapH-”對其如此評價：

我使用DevExpress XPO已有11年了。今年10月，它開始支持.NET Standard 2.0。盡管它是一個商業產品，但支持.NET Core的首個.NET測試版（v17.2.2）將對所有的用戶免費使用。進一步更新盡管需要付費，但是其中包括了視覺設計工具和技術支持。雖然該ORM不同于EF，并且推出的時間更長（如果我沒有記錯的話，它的第一個版本是針對.NET 1.1發布的），但是其中基本包含了各種規模應用程序所需的所有特性。它的演示和教程提供于https://github.com/DevExpress/XpoNetCoreDemos。

看完上述內容，你們對用于.NET Core的ORM是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。