DAL 和 ORM 之间的界线在哪里？
这些术语经常互换使用，并且显然存在相当大的重叠，但似乎也常常暗示人们通过说系统是 ORM 来强烈暗示某些东西，而系统是 DAL 并没有暗示这一点。 那是什么？ 如果有的话，区分这些类型系统的关键点是什么？
例如，假设我有一些实现数据库、表、列和行类的代码，通过自动分析现有数据库来填充它们，允许简化交互等。 它理解、强制执行并利用数据库实体之间的结构关系，例如外键。 所有实体模型都可以进行子类化，以将特定于表的功能加载到它们上。
这在多大程度上是 DAL？ 它在多大程度上是一个 ORM？ 为什么？
The terms are often thrown around interchangeably, and there's clearly considerable overlap, but just as often it seems implied that people see something strongly implied by saying that a system is an ORM that isn't implied by it being a DAL. What is that? What, if any, are the key points that differentiate these types of system?
For example, let's say I have some code that implements Database, Table, Column and Row classes, populating them by automatic analysis of an existing database, allowing simplified interaction and so on. It understands, enforces, and takes advantage of structural relationships between database entities, such as foreign keys. All the entity models can be subclassed to load table-specific functionality onto them.
To what extent is this a DAL? To what extent is it an ORM? Why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
ORM = 对象关系映射
在 ORM 中，应用程序中的类/对象被映射到数据库表和操作以实现持久性（有时是自动的）。
DAL = 数据访问层
在 DAL 中，数据库操作隐藏在代码外观后面。
ORM 是 DAL 的一种，但并非所有 DAL 都是 ORM。
ORM = Object-Relational Mapping
In an ORM, classes/objects in the application are mapped to database tables and operations for persistence, sometimes automagically.
DAL = Data-Access Layer
In a DAL, database operations are hidden behind a code facade.
An ORM is a kind of DAL, but not all DALs are ORMs.
我认为 ORM 能够将任何对象集映射到关系数据库； 而 DAL 是特定于您的应用程序的，并且可能无法自然地扩展以支持其他对象。
不仅如此，ORM 特别关注将类映射到数据库实体/从数据库实体映射类，而 DAL 可能只是您访问数据库中的数据的一种方式，而不需要任何映射。
I think an ORM is capable of mapping any set of objects to a relational database; whereas a DAL is specific to your application, and probably couldn't naturally be extended to support other objects.
Not only that, but a ORM specifically is concerned with mapping classes to/from the database entities, while a DAL may simply be a way for you to access the data in a database, without any mapping.
连接到任何不保存对象的存储系统的任何面向对象的 DAL 都会实现 ORM。 ORM 一般被理解为类似于 Hibernate 的意思，但重要的是阻抗不匹配的处理。
[扩展]
在数据级别，当您将一种类型（关系）的数据映射到另一种类型（OO）的数据时，会发生阻抗不匹配。
例如，您在 DAL 中见过多少次类似下面的行？
或者另一方面，
映射原始数据类型时会出现许多问题。
在对象级别，您的 DAL 应该返回您打算使用的结构。 无论是某种业务对象还是只是一堆原始数据。 您自己的 DAL 和 ORM 都需要处理这个问题。
在设计级别，您构造的对象反映了您存储的数据。 因此可能会出现结构性差异。 这些也会在 ORM 解决方案中为您处理，但您将被迫在 DAL 中执行相同的操作。 例如，在面向对象的代码中，最好能实现适当的继承，但这并不容易转化为相关的东西。
我只是想指出 ORM 这个术语是为了推动产品而创造的，这些产品可以自动化您在 DAL 中已经要做的许多事情。 ORM 解决方案将使生活变得更轻松，并提供大量质量/性能优势。 但这并没有改变这样一个事实：DAL 的主要组件之一是创建您自己的 ORM。
Any object orientated DAL connecting to any storage system that is not saving objects implements an ORM. ORM is generally understood to mean something like Hibernate, but the important thing is the handling of impedance mismatches.
[Expanded]
At a data level, an impedance mismatches occur when you are mapping data of one type (relational) into data of another (OO).
For instance, how many times have you seen a line like below in your DAL?
Or the other side
Many issues come up when mapping your primitive data types.
At a object level, your DAL should be returning the structures you intend to use. Be it some sort of business object or just a bunch of raw data. Both your own DAL and the ORM need to handle this.
At a design level, the objects you construct are reflective of your stored data. So a structural difference can occur. These are also handled for you within ORM solutions, but you would be forced to do the same within a DAL. For example, within your OO code it would be nice to implement proper inheritance, but that does not covert easily into something relational.
I just wanted to point out that ORM is a term coined to push products that automate a lot of what you would already have to do within your DAL. The ORM solutions will make life easier and provide a large number of quality/performance benefits. But that doesn't change the fact that one of the major components of your DAL is creating your own ORM.
当我开始编程时，ORM 还不存在。 当第一个 ORM 出现时，它们是用于创建 DAL 的外部工具。 现在，DAL 和 ORM 已经混合在一起。 这就是为什么许多开发人员交替使用这些术语的原因。
充当 DAL 功能的 ORM 最著名的示例是 NHibernate。 其他示例包括 Subsonic 和 CSLA.NET。 这些都是.NET 工具。 IIRC，ORM 工具始于 Java 世界。 其他技术栈随后复制了 Java 所做的事情。
ORM didn't exist when I started programming. When the first ORMs came out, they were external tools used to create the DAL. Now days, DAL and ORM have intermingled. That's why a lot of developers use the terms interchangeably.
The most well known example of an ORM that functions as a DAL is NHibernate. Other examples are Subsonic and CSLA.NET. These are all .NET tools. IIRC, ORM tools started in the Java world. Other technologies stacks then copied what Java has done.