尽管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的作者发起了一个。

LLBLGen Pro Runtime Framework也不同于EF/EF Core，它并非绑定于上下文（Context）的。每个实体无需维持一个打开的上下文，就可以追踪自身的改变，并在内存中操作对象图。该特性无疑会受到DBA的欢迎，因为无需维持打开的上下文，意味着不需要维持一个打开的数据库连接，否则需要操作数据库的连接池。

与大多数用于.NET Core的ORM一样，。但这些限制主要局限于.NET Core本身的缺失特性。例如，TransactionScope目前尚不被SqlClient支持、很少一部分对象是可二进制序列化等。

Dapper

另一种是广为人知的微ORM（Micro-ORM）产品。Dapper常被认为是最快的ORM，几乎总是保持着.NET ORM基准测试的头名位置。

通常使用Dapper实现对原始SQL的调用并物化查询结果，因此它在.NET和.NET Core上的工作情况基本相同。Dapper不同于完备ORM，它并不提供任何SQL生成功能。虽然许多开发人员并不相信由ORM生成的SQL，但这还是会令Dapper在使用上要比其它ORM产品更为繁琐。

LINQ to DB

称自己是“超出Dapper、Massive、PetaPoco等微ORM产品一步之遥”。它不具备一些在Entity Framework中使用会引发性能问题的特性，例如更改追踪。

LINQ to DB中的Join操作有些不同。在EF中，任何需要执行“Join”操作之处，事实上是作为子对象或集合（Collection）对待的。所生成的SQL自然会使用Join操作，但是当结果集被物化为对象后，SQL语句的执行就不再依赖于Join操作了。

，具体实现为“Left Join”和“Inner Join”操作。如果使用EF解释LINQ，那么生成语句在语法虽然略显奇特，但更好地匹配了数据库的实际工作情况。

DevExpress XPO

（XPO）是一种商业产品。Reddit用户“-GrapH-”对其如此评价：

\

我使用DevExpress XPO已有11年了。今年10月，它开始支持.NET Standard 2.0。尽管它是一个商业产品，但支持.NET Core的首个.NET测试版（v17.2.2）将对所有的用户免费使用。进一步更新尽管需要付费，但是其中包括了视觉设计工具和技术支持。虽然该ORM不同于EF，并且推出的时间更长（如果我没有记错的话，它的第一个版本是针对.NET 1.1发布的），但是其中基本包含了各种规模应用程序所需的所有特性。它的演示和教程提供于。

\

你的选择是什么？

现有多种.NET Core可用的ORM。如果你已使用其中一种达数月时间，欢迎将你的认识反馈给我们。

译者注：在原文评论中，有人指出NHibernate 5和EntityLite也支持.NET Core 2.0。

查看英文原文：