这些术语通常可以互换使用，并且显然存在相当大的重叠，但似乎暗示人们经常看到通过说系统是 ORM 而不是因为它是 DAL 而暗示的东西。那是什么？如果有的话，区分这些类型系统的关键点是什么？
例如，假设我有一些代码实现了 Database、Table、Column 和 Row 类，通过对现有数据库的自动分析来填充它们，允许简化交互等等。它理解、执行和利用数据库实体之间的结构关系，例如外键。所有实体模型都可以进行子类化，以将特定于表的功能加载到它们上。
这在多大程度上是 DAL？它在多大程度上是一个 ORM？为什么？
在 ORM 中，应用程序中的类/对象被映射到数据库表和操作以实现持久性，有时是自动的。
在 DAL 中，数据库操作隐藏在代码外观之后。
我认为 ORM 能够将任何对象集映射到关系数据库；而 DAL 是特定于您的应用程序的，并且可能无法自然地扩展以支持其他对象。
不仅如此，ORM 还特别关注与数据库实体之间的映射类，而 DAL 可能只是您访问数据库中数据的一种方式，无需任何映射。
任何连接到任何不保存对象的存储系统的面向对象的 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 的事实。
当我开始编程时，ORM 并不存在。当第一个 ORM 出现时，它们是用于创建 DAL 的外部工具。现在，DAL 和 ORM 已经混合在一起了。这就是为什么许多开发人员可以互换使用这些术语的原因。
用作 DAL 的 ORM 最著名的示例是 NHibernate。其他示例是 Subsonic 和 CSLA.NET。这些都是 .NET 工具。IIRC，ORM 工具起源于 Java 世界。其他技术栈随后复制了 Java 所做的事情。