orm和ADO.net有什么区别?

时间:2016-11-09 11:53:24

标签: c# entity-framework linq-to-sql orm ado.net

我正在读一本书,它说:"如果您将使用ADO.NET创建自己的数据访问层以访问您的数据库,那么无论数据模式是否存在,您都将受到的影响微乎其微。但是,如果您使用的是O / RM,则您的灵活性将受到您使用的工具的限制"。 ADO.NET和任何其他ORM之间的主要区别是什么?

2 个答案:

答案 0 :(得分:7)

  

ADO.NET提供对SQL Server等数据源的一致访问   和XML,以及通过OLE DB和ODBC公开的数据源。   数据共享使用者应用程序可以使用ADO.NET连接到这些应用程序   数据源并检索,处理和更新它们的数据   包含。

     

ADO.NET将数据访问与数据操作分离为离散   可以单独使用或串联使用的组件。 ADO.NET包括   用于连接数据库的.NET Framework数据提供程序,执行   命令和检索结果。这些结果要么得到处理   直接放在ADO.NET DataSet对象中以便公开   以特别方式向用户提供,与来自多个的数据相结合   来源,或在层之间传递。也可以使用DataSet对象   独立于.NET Framework数据提供程序来管理本地数据   应用程序或源自XML。

ADO.NET是一个层,允许您连接到数据库并使用SQL连接,命令和参数对其进行修改。 ADO.NET MSDN

  

对象关系映射(ORM,O / RM和O / R映射工具)   计算机科学是一种用于转换数据的编程技术   在面向对象编程中的不兼容类型系统之间   语言。这实际上创建了一个虚拟对象数据库"那   可以在编程语言中使用。这两个都是免费的   和可用于执行对象关系的商业包   映射,虽然一些程序员选择构建自己的ORM   工具。

Entity FrameworkNHiberante是ORM。这意味着您不通过SQL连接,命令,参数进行操作 - ORM为您完成操作,它允许以OOP方式映射数据库结构:您可以使用C#中的对象添加,读取,更新,删除数据库中的记录。您只需要正确地将对象映射到DB。 Entity Framework建立在ADO.NET之上,它在里面使用ADO.NET。 SQL语句由ORM生成。 ORM

通常,在没有ORM的情况下访问DB会更快,但您应该提供更多代码行。如果要以OOP方式操作数据库并编写更易读的代码,则应选择ORM。这取决于你的目的选择什么。

Micro ORM(Dapper,BLToolkit)允许您编写SQL查询并将参数映射到对象属性。一般来说,微型ORM比完整ORM具有更好的性能,但ADO.NET仍然更快。

此外,StackOverflow还有一些问题和答案:EF vs ADO.NET

答案 1 :(得分:2)

  • 一路走来,我了解到开发人员讨厌使用DataSetsDataReaders
  • .NET 平台定义了许多名称空间,使您可以 与关系数据库系统进行交互。总的来说, 这些命名空间称为ADO.NET.
  • ORM 代表Object-Relational Mapper,它用于将对象与关系世界映射。顾名思义,builds a relation / maps objects (model) to database objects(tables).
  • ADO.NET是将应用程序连接到数据库并让开发人员完全控制数据库操作的传统方式,而ORM建立在ADO.NET之上并使用{{1 }}隐含。
  • 简而言之,使用 NHibernate之类的ORM,实体框架使ADO.NET
  • 在内部处理对象(模型)的映射更加轻松
  • 当您使用ORM.时,并不是所有东西都在您手中,因为所有查询都是由ORM本身生成的。现在,我们不知道这些查询是否已优化
  

在您的应用程序的性能是首要考虑并且绝对重要的情况下 OR ,在您知道应用程序在不久的将来会变得巨大的情况下,建议使用ORM而不是ADO.NET,因为它会使您的应用程序变得繁重。

  • 解决方案是Entity Framework,例如 Dapper,BLToolkit 。这些提供了开发人员所需的本质-一种将数据库操作映射到强类型类的简便方法。
  • 在某些方面对LINQ的支持甚至使它变得更好。但是,其中一些Micro-ORM的主要优点是其Micro ORM's

智慧之语:

  1. raw speed.只是进行映射,但是您需要编写很多代码,Dapper不仅在映射上还要做很多事情。因此EF会变慢。
  2. 我还可以说,纯EFADO.NET更快,DapperOLEDB更快,而ADO.NET可以比{{1} }
  3. 因此,如果我对性能很认真,可能会避免使用任何ODBC