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

Question

我实际上被困在三层结构中。我浏览了互联网，并发现了两个术语“数据库抽象层”和“数据访问层”。

这两者之间有什么区别？

- Starx

Answer 1

数据访问层=针对你的应用程序领域创建、读取、更新、删除（CRUD）操作

数据抽象层=执行通用数据库操作，如连接、命令、参数，使你隔离特定于供应商的数据库库，并提供一个高级API来访问数据，无论你是否使用MySQL、Microsoft SQL Server、Oracle、DB2等...

- Craig McKeachie

---

您使用了术语“数据抽象层”，而其他答案似乎使用“数据库抽象层”。尽管所有答案都谈论相同的事情，即对DB进行抽象。我的问题是：这些术语可以互换使用吗？ - dvlper

Answer 2

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

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

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

数据抽象层通常是完整的ORM（对象关系映射器），理论上可以避免了对底层数据库结构的理解或对SQL的任何知识。其语法可能如下所示：

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

所有对象都可以完全填充所有字段，并可能与任何父对象或子对象连接，如果您设置了这种方式。

但是，这种抽象是有代价的。我个人认为，像Doctrine或Propel之类的ORM是不必要且效率低下的。在大多数情况下，一个简单的数据访问层就足够了，对于需要特殊注意的任何内容，手动使用SQL即可，而不必为了一些语法糖而破坏应用程序的性能。这个领域是一个相当激烈的辩论，所以我不会再深入探讨了。

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

- Lotus Notes

---

我对你的回答有些困惑。能不能再简单一些呢？或者再给几个例子，可能会更有帮助。我真的很困惑。 - kamal

你对什么感到困惑？@kamal - Harry

这个回答一开始可能有点与Craig的回答相矛盾，因为你提到了数据抽象层，而他提到了数据库抽象层。很好，你强调了区分它们的重要性。我认为，由于数据抽象层在访问数据方面更加“接近”（不是抽象化的意思，即使名称暗示了这一点）数据访问层，而不是数据库抽象层。感谢你的回答。 - FantomX1

Answer 3

来自维基百科：

数据访问层

计算机软件中的数据访问层（DAL）是程序的一层，它提供对持久存储中存储的数据的简化访问，例如实体关系数据库。例如，DAL可能返回一个对象的引用（在面向对象编程方面），其中包含其属性，而不是来自数据库表的字段行。这允许使用更高级别的抽象创建客户端（或用户）模块。通过创建一组直接引用相应的一组数据库存储过程的数据访问方法类，可以实现这种模型。另一种实现可能会从文件系统检索或写入记录。 DAL将底层数据存储的复杂性隐藏在外部世界之外。例如，可以创建一个类和一些存储过程来访问特定数据库表，而不是使用诸如插入、删除和更新之类的命令。该类中的方法将调用存储过程，该存储过程将返回包含请求值的对象。或者，可以在数据访问层中执行类似于registeruser或loginuser的简单函数中的插入、删除和更新命令。

简而言之，将业务对象推送到/从持久性/存储层的基本CRUD功能/逻辑在此处实现。对于大多数情况，您可能只需要这个。ORM映射、模型的业务对象接口等都在这里。 数据库抽象层

数据库抽象层是应用程序编程接口，它统一了计算机应用程序和数据库（如SQL Server、DB2、MySQL、PostgreSQL、Oracle或SQLite）之间的通信。传统上，所有数据库供应商都提供专门针对其产品定制的接口，这使得应用程序员必须为他或她想要支持的所有数据库接口实现代码。数据库抽象层通过提供一致的API减少了开发人员的工作量，并尽可能地隐藏了数据库特定的内容。有许多具有不同接口的抽象层在众多的编程语言中存在。

基本上，它是一种额外的抽象层，使您可以针对供应商无关的接口进行CRUD操作，并更少地担心各种数据库供应商的实现细节。只有在您想要支持多个数据库时才需要使用此功能。ORM、Micro ORM、wrappers、generic driver classes等处理连接建立、参数处理、执行等的内容都在此处。这只是一个额外的层，就在Persistence/Storage层之前。在三层术语中，这两个层次都属于同一个层次，因为它们在逻辑上不是分开的。

---

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

- nawfal