DAL和ORM之间的界线在哪里？

这些术语经常交替使用，显然有相当多的重叠，但同样经常的是，人们认为一个系统是一个ORM而不是DAL意味着它是一个DAL，这似乎意味着人们看到了一些强烈的暗示。那是什么？区分这些类型系统的关键点是什么（如果有的话）

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

---

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

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

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

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

DAL=数据访问层 在DAL中，数据库操作隐藏在代码外观后面

---

ORM是DAL的一种，但并非所有DAL都是ORM。ORM在我开始编程时并不存在。当第一个ORM出现时，它们是用于创建DAL的外部工具。现在，DAL和ORM已经混合在一起了。这就是为什么许多开发人员可以互换使用这些术语

---

作为DAL的ORM最著名的例子是NHibernate。其他示例包括亚音速和CSLA.NET。这些都是.NET工具。IIRC，ORM工具起源于Java世界。其他技术堆栈随后复制了Java所做的工作。

任何面向对象的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。

您能详细介绍阻抗失配的处理吗？@chaos-为什么要使用术语标签？？DAL和ORM是完美的技术acronyms@DJ当前位置我不是想用“行话”来暗示这些术语有问题。正如Rich B的另一位旁观者所建议的，我正试图被引导。计算机术语可以被外人称为行话——但我们这里的所有软件专家——这对我们来说都不是行话——否则这里几乎所有的帖子都必须贴上标签jargon@DJ：嗯，是的，我想你是对的i18n’和‘downlown funargs’以及‘lvalue’在某种程度上看起来确实是行话，而数据访问层和对象关系映射并没有。我不确定这是否向那些还不知道它说了什么的人描述了什么。DAL用户可以争辩说，它将数据库表和操作映射到类和对象。ORM可以被看作是在门面后面隐藏东西。@[le dorfier]：DAL中不需要将对象和类映射到表。RunSql（“Select*from MyTable”，rowCollection）是一个DAL，但不是一个ORM（严格意义上）。请注意：DAO是DAL的OOP形式。