数据库抽象层和数据访问层有什么区别？答案

【问题标题】：What is the difference between Database Abstraction Layer & Data Access Layer?数据库抽象层和数据访问层有什么区别？
【发布时间】：2011-02-19 18:52:59
【问题描述】：

我实际上被困在 3 层结构中。我在网上冲浪，发现了两个术语“数据库抽象层”和“数据访问层”。

两者有什么区别？

【问题讨论】：

标签： data-access-layer 3-tier dbal doctrine-dbal

【解决方案1】：

数据访问层 = 特定于您的应用程序域的创建、读取、更新、删除 (CRUD) 操作

Data Abstraction Layer= 执行通用数据库操作，如连接、命令、参数，将您与供应商特定的数据库隔离开来，并提供一个高级 api 用于访问数据，无论您使用 MySQL、Microsoft SQL Server、Oracle、DB2 等。 ..

【讨论】：

您使用了术语定义的“数据抽象层”，而其他答案似乎使用了“数据库抽象层”。虽然，所有答案都在谈论同一件事，即对数据库的抽象。我的问题：这些术语可以互换使用吗？

【解决方案2】：

我的理解是，数据访问层实际上并不抽象数据库，而是使数据库操作和查询构建更容易。

例如，数据访问层通常具有与 SQL 语法非常相似的 API，但仍需要了解数据库的结构才能编写：

$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);

数据抽象层通常是成熟的 ORM（对象关系映射器），理论上无需了解任何底层数据库结构或具备任何 SQL 知识。语法可能是这样的：

Factory::find('Users', 10)->filter('rank > 0');

并且所有对象都可能被所有字段完全填充，如果您这样设置，可能会与任何父对象或子对象连接。

但是，这种抽象是有代价的。我个人认为 ORM 之类的教义或推进是不必要且低效的。在大多数情况下，一个简单的数据访问层就可以了，对于需要特别注意的任何事情都使用手动 SQL，而不必为了某些语法糖而破坏应用程序的性能。这个领域是一个非常激烈的争论，所以我不会再讨论了。

如果您的意思是数据基础抽象层，那么它将类似于 PDO，以便您的代码可以用于更多的数据库供应商。我相信 PDO 可以与 MySQL、PostgreSQL 和 mysqli 等一起使用。

【讨论】：

你的回答让我有点困惑。你能不能让它更简单一点。可能有更多的例子可能会有所帮助。我真的很困惑。
你对什么感到困惑？ @kamal
当你提到数据抽象层和数据库抽象层时，这个答案首先错误地看起来与 Craig 的答案有点矛盾。你强调区分它很好。由于数据抽象层更“接近”（以访问数据的方式，而不是像名称所暗示的那样抽象）数据访问层而不是数据库抽象层imo。感谢您的回答。

【解决方案3】：

来自维基：

Data Access Layer

计算机软件中的数据访问层 (DAL) 是提供对存储在某种持久性存储，例如实体关系数据库。

例如，DAL 可能会返回对对象的引用（以面向对象的编程) 用它的属性来代替数据库表中的一行字段。这允许客户端（或用户）要使用更高抽象级别创建的模块。这一种模型可以通过创建一个数据访问类来实现直接引用存储的相应数据库集的方法程序。另一种实现可能会检索或写入进出文件系统的记录。 DAL 隐藏了来自外部世界的底层数据存储。

例如，而不是使用诸如插入、删除和更新以访问数据库中的特定表、类和一些可以在数据库中创建存储过程。手续将从类内部的方法调用，该方法将返回一个包含请求值的对象。或者，插入、删除和更新命令可以在简单的函数中执行，比如 registeruser 或 loginuser 存储在数据访问层中。

简而言之，您在业务对象上的基本 CRUD 功能/逻辑 可以从 Persistance/Storage 层推入/拉出。在大多数情况下，您可能只需要这个。 ORM 映射、Model 的业务对象的接口等都属于这里。

Database Abstraction Layer

数据库抽象层是应用程序编程接口它统一了计算机应用程序和数据库，例如 SQL Server、DB2、MySQL、PostgreSQL、Oracle 或 SQLite。传统上，所有数据库供应商都提供自己的为他们的产品量身定制的界面，这留给应用程序员为所有数据库接口实现代码他或她愿意支持。数据库抽象层减少通过向开发人员提供一致的 API 和尽可能隐藏这个接口后面的数据库细节。存在许多具有不同接口的抽象层多种编程语言。

基本上，它是一个额外的抽象层，因此您CRUD 可以针对独立于供应商的接口而不必担心各种数据库供应商的实现细节。只有当您想要支持多个数据库时才需要它。处理连接建立、参数处理、执行等的ORM、Micro ORM、包装器、通用驱动程序类等等都属于这里。它只是在持久性/存储层之前的一个附加层。在 3 层术语中，这两个层都归于一层，因为它们在逻辑上不是独立的。

总而言之，DAL 是关于数据的，DbAL 是关于数据库的。 DAL 定义操作，DbAL 操作。 DAL 位于 DbAL 后面，而 DbAL 就在实际 Db 后面。 DAL 调用 DbAL。 DAL 是将业务逻辑（在模型中）与 CRUD 逻辑分开的好东西，而 DbAL 很少需要（但我喜欢它）。 DAL 是更高级的设计映射，DbAL 是更底层的架构和实现。两者都将职责分开。 ORM 是一种对你都有好处的大型结构。我不确定在使用 ORM 时如何将它们分开。你不需要，因为 ORM 会为你处理所有这些。理想情况下，无论如何我都会在一个项目中使用 DAL，而在另一个项目中使用 DbAL，我会简单地将其称为持久层，因为将 Db 和对它的操作分开是没有意义的。

【讨论】：