class="topic_img" alt=""/>
英文原文：ORMs for .NET Core
尽管 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。如果你已使用其中一种达数月时间，欢迎将你的认识反馈给我们。
译者注：在原文评论中，有人指出 NHibernate 5 和 EntityLite 也支持 .NET Core 2.0。
相关文章
