用于.NETCore的ORM是怎样的

今天就跟大家聊聊有关用于.NET Core的ORM是怎样的,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

创新互联公司服务热线:13518219792,为您提供成都网站建设网页设计及定制高端网站建设服务,创新互联公司网页制作领域十年,包括边坡防护网等多个领域拥有丰富的网站运维经验,选择创新互联公司,为企业锦上添花。

尽管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是怎样的有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


本文名称:用于.NETCore的ORM是怎样的
文章起源:http://ybzwz.com/article/josooj.html