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

Question

我实际上陷入了三层结构。我上网发现了两个术语“数据库抽象层”和“数据访问层”。

两者有何区别？

Answer 1

我的理解是，一个数据访问层，实际上并不抽象的数据库，而是让数据库操作和查询更简单。

例如，数据访问层通常具有的API非常类似于SQL语法仍然需要为了数据库的结构的知识来编写：

$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的等等，我相信了。

Answer 2

数据访问层=创建，读取，更新，删除（CRUD）操作特定于应用程序域

数据抽象层执行=通用数据库操作等的连接，命令，参数从供应商特定的数据库绝缘你以及用于访问数据提供一个高水平的API无论是否使用MySQL，的Microsoft SQL服务器，Oracle，DB2，等..

Answer 3

来自维基：

数据访问层

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

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

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

简而言之，你的基本 CRUD 功能/逻辑 向持久性/存储层推送/拉取的业务对象落在此处。对于大多数情况，您可能只需要这个。 ORM映射、Model业务对象接口等 跌倒在这里。

数据库抽象层

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

基本上，它是一个额外的抽象层，以便您 增删改查 反对供应商独立的接口，不用担心各个数据库供应商的实现细节。仅当您想要支持多个数据库时才需要这一点。 ORM、微型 ORM、包装器、通用驱动程序类，无论名称是什么，等等 处理连接建立、参数处理、执行等的部分都在这里。它只是持久/存储层之前的附加层。在三层术语中，这两层都属于一层，因为它们在逻辑上不是独立的。

---

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