当前位置：文江博客话题详情

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

发布于 2024-09-02 03:27:32 字数 77 浏览 11 评论 0原文

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

两者有何区别？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

忘东忘西忘不掉你 2024-09-09 03:27:52

来自 Wiki：

数据访问层

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

简而言之，业务对象上用于推送到持久性/存储层或从持久性/存储层拉取的基本 CRUD 功能/逻辑就落在了这里。对于大多数情况，您可能只需要这个。 ORM 映射、模型业务对象的接口等都属于这里。

数据库抽象层

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

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

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

From Wiki:

Data Access Layer

A data access layer (DAL) in computer software, is a layer of a
computer program which provides simplified access to data stored in
persistent storage of some kind, such as an entity-relational
database.
For example, the DAL might return a reference to an object (in terms
of object-oriented programming) complete with its attributes instead
of a row of fields from a database table. This allows the client (or
user) modules to be created with a higher level of abstraction. This
kind of model could be implemented by creating a class of data access
methods that directly reference a corresponding set of database stored
procedures. Another implementation could potentially retrieve or write
records to or from a file system. The DAL hides this complexity of the
underlying data store from the external world.
For example, instead of using commands such as insert, delete, and
update to access a specific table in a database, a class and a few
stored procedures could be created in the database. The procedures
would be called from a method inside the class, which would return an
object containing the requested values. Or, the insert, delete and
update commands could be executed within simple functions like
registeruser or loginuser stored within the data access layer.

In short, your basic CRUD functionalities/logics on business objects to push to/pull from Persistance/Storage layer falls here. For most cases you might want just this. ORM mapping, interfaces of business objects of Model etc fall here.

Database Abstraction Layer

A database abstraction layer is an application programming interface
which unifies the communication between a computer application and
databases such as SQL Server, DB2, MySQL, PostgreSQL, Oracle or
SQLite. Traditionally, all database vendors provide their own
interface tailored to their products which leaves it to the
application programmer to implement code for all database interfaces
he or she would like to support. Database abstraction layers reduce
the amount of work by providing a consistent API to the developer and
hide the database specifics behind this interface as much as possible.
There exist many abstraction layers with different interfaces in
numerous programming languages.

Basically, its an additional layer of abstraction so that you CRUD against vendor independent interfaces and worry less about implementation details of various database vendors. You will need this only if you would want to support more than one database. ORMs, Micro ORMs, wrappers, generic driver classes, whatever the name is, etc that deals with connection establishment, parameter handling, execution etc fall here. It's just an additional layer just before Persistance/Storage layer. In 3 tier terminology, both these layers fall under one as they are not logically separate.

To summarize, DAL is about data, DbAL is about database. DAL defines operations, DbAL operates. DAL sits behind DbAL which is just behind actual Db. DAL calls DbAL. DAL is a good thing to separate business logics (in Model) from CRUD logics, while DbAL is seldom needed (but I love it). DAL is more high level design mapping, DbAL is more low level architecture and implementation. Both separates responsibilities. ORMs are massive structures that does both for you. I'm not sure how you separate them when using ORMs. You need not since ORMs handle all that for you. Ideally, I would anyway have DAL in one project, and DbAL in another which I would simply call Persistence layer since there is no point in separating Db and operations on it.

回复收藏 0 原文

佞臣 2024-09-09 03:27:51

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

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

回复收藏 0 原文

灯角 2024-09-09 03:27:51

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

例如，数据访问层通常具有与 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 等一起使用。

My understanding is that a data access layer does not actually abstract the database, but rather makes database operations and query building easier.

For example, data access layers usually have APIs very similar to SQL syntax that still require knowledge of the database's structure in order to write:

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

Data abstraction layers are usually full blown ORM's (Object-Relational Mappers) that theoretically prevent the need to understand any underlying database structure or have any knowledge of SQL. The syntax might be something like this:

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

And all the objects might be fully populated with all the fields, possibly joined with any parent or child objects if you set it that way.

However, this abstraction comes with a price. I personally find ORM's like doctrine or propel to be unnecessary and inefficient. In most cases a simple data access layer will do fine, with manual SQL for anything that requires special attention, instead of having to destroy your application's performance for some syntactic sugar. This area is a pretty heated debate so I won't go into it anymore.

If you meant database abstraction layer, then it would be something along the lines of PDO, so that your code can be used for a larger number of database vendors. PDO works with MySQL, PostgreSQL, and mysqli among others, I believe.

回复收藏 0 原文

~没有更多了~