ORM =对象关系映射

Question

这些术语经常互换，并且显然存在相当大的重叠，但同样常见的是，人们看到一种强烈暗示的东西，即系统是一个ORM并不是DAL所暗示的。那是什么？如果有的话，区分这些类型系统的关键点是什么？

例如，假设我有一些实现Database，Table，Column和Row类的代码，通过自动分析现有数据库来填充它们，允许简化交互等等。它理解，实施并利用数据库实体（如外键）之间的结构关系。可以对所有实体模型进行子类化，以将特定于表的功能加载到它们上。

这在多大程度上是DAL？ ORM在多大程度上？为什么呢？

Answer 1

在ORM中，应用程序中的类/对象被映射到数据库表和操作以实现持久性，有时是自动的。

DAL =数据访问层

在DAL中，数据库操作隐藏在代码外观之后。

Answer 2

我认为ORM能够将任何对象集映射到关系数据库;而DAL特定于您的应用程序，并且可能无法自然地扩展为支持其他对象。

不仅如此，ORM还特别关注与数据库实体之间的映射类，而DAL可能只是您访问数据库中数据的一种方式，而不是任何映射。

Answer 3

任何面向对象的DAL连接到任何不保存对象的存储系统都会实现ORM。 ORM通常被理解为类似于Hibernate的东西，但重要的是处理阻抗不匹配。

[展开]

在数据级别，当您将一种类型（关系）的数据映射到另一种类型（OO）的数据时，会发生阻抗不匹配。

例如，您在DAL中看到过多少次这样的行？

db.AddInParameter(dbCommand, "Name", DbType.String, name);

或另一方

customerId = Convert.ToInt64(dr["CustomerID"].ToString());

映射原始数据类型时会出现许多问题。

在对象级别，您的DAL应该返回您打算使用的结构。无论是某种业务对象还是一堆原始数据。你自己的DAL和ORM都需要处理这个问题。

在设计级别，您构建的对象反映了您存储的数据。因此可能发生结构差异。这些也在ORM解决方案中为您处理，但您将被迫在DAL中执行相同操作。例如，在你的OO代码中，实现正确的继承会很好，但这并不容易转化为关系。

我只是想指出，ORM是一个用来推动产品的术语，可以自动完成你在DAL中必须做的很多工作。 ORM解决方案将使生活更轻松，并提供大量的质量/性能优势。但这并没有改变DAL的一个主要组件是创建自己的ORM这一事实。

Answer 4

当我开始编程时，ORM不存在。当第一个ORM出现时，它们是用于创建DAL的外部工具。现在，DAL和ORM混合在一起。这就是许多开发人员交替使用这些术语的原因。

作为DAL的ORM最着名的例子是NHibernate。其他例子是Subsonic和CSLA.NET。这些都是.NET工具。 IIRC，ORM工具始于Java世界。其他技术堆栈随后复制了Java所做的事情。