php - 数据库抽象层——那是什么？

Question

我有一些关于数据库抽象层(dbal)的基本问题。我想更好地理解这一点。我已经知道 dbal 是一个应用程序编程接口(interface)。我使用PHP作为我的基本编程语言，使用MySQL作为数据库，所以我的问题将基于它。让我们开始...

• MySQL Shell 已经是更深层次意义上的 dbal 了吗？我给你一个例子，下面的命令将打印结果，我可以在我的脚本上处理它。所以在我看来，它就像一个 api，一个非常糟糕的 API，但它会起作用。

  mysql --batch -u root -p -e "从 foobar 选择 *"

• MySQL 改进扩展和 PHP 数据对象也是 dbal 吗？我会说是的，因为它为我提供了一个很好的 API，用于在 PHP 中处理与数据库相关的内容。

• 很长一段时间我认为在一个 api 中处理不同的数据库是 dbal 背后的主要思想。然而我意识到这是与数据库无关的而不是 dbal。因此，当 dbal 可以处理多个数据库时，它就与数据库无关，我是对的吗？

• 最后一个问题。在我参与这个主题之后，我意识到 dbal 是门面。好吧，每个 dbal 都是一个编程接口(interface)，这一定意味着，每个 api 都是设计模式意义上的外观？这是正确的吗？

感谢您的帮助:)

Answer 1

虽然您可能认为任何隐藏与数据库的低级通信细节的 API 从字面意义上来说都是“抽象层”，但术语“数据库抽象层”通常用于指代更具体的层。 API 类型。

我希望 DBAL 至少有潜力支持不止一种类型的 DBMS；名称中的“抽象”意味着 API 并未与底层协议(protocol)或驱动程序紧密耦合。

MySQLi PHP extension将自己称为“连接器”，它包装了较低级别的“驱动程序”，尽管这个术语并不是特别广泛。对于大多数 PHP 用户来说，它只是“MySQL 驱动程序”，与 DBMS 的功能紧密相关。

PHP的PDO扩展当然可以看作是DBAL，因为它统一了对各种数据库驱动程序的访问，并抽象了一些概念，例如查询参数。另一方面，它是一个相当“低级”的抽象，因为它暴露了底层系统的很多复杂性。 The introduction in the manual将其称为“数据访问抽象层”，以区别于“成熟的数据库抽象层”。

Doctrine DBAL另一方面，它为事务等功能提供了更丰富的 API，并包含一个抽象 SQL 语法差异的查询构建器。使用 PDO 编写的代码仍然需要对特定 DBMS 使用正确的语法和选项，而使用 Doctrine DBAL 编写的代码理论上可以在任何受支持的 DBMS 上运行，无需修改。

甚至更丰富的抽象也是可能的，例如对象关系映射器，例如 Doctrine ORM 。这些通常不会被称为 DBAL，尽管严格来说它们确实提供了一个抽象数据库的层。

请记住，所有这些只是为了方便引用事物 - 没有法律规定应用程序必须使用特定的层集，或者这些层必须适合某些类别。设计模式也是如此，因此您关于 Facade 模式的问题在一般情况下并不能真正回答 - 如果您正在实现 DBAL，您可能会使用 Facade 模式作为如何构建它的指南；但您可能在这样的环境中工作，这不是理解架构的有用方法。