定义数据访问层

Posted 2023-02-24

【中文标题】定义数据访问层

【英文标题】：Define data access layer

【发布时间】：2010-09-21 21:49:40

【问题描述】：

似乎每个人都知道您应该明确区分 GUI、业务逻辑和数据访问。我最近与一位吹嘘始终拥有干净的数据访问层的程序员交谈。我查看了这段代码，结果发现他的数据访问层只是一个包含一些 SQL 方法（如 ExecuteNonQuery 和 ExecuteReader）的小类。事实证明，在他的页面背后的 ASP.NET 代码中，他有大量的 SQL 硬编码到 page_load 和其他事件中。但他发誓他正在使用数据访问层。

所以，我抛出这个问题。您将如何？

【问题讨论】：

访问数据库和拥有数据访问层是不一样的。也就是说，需要使用某种形式的数据访问层来访问数据库，所以我可以理解混乱

【参考方案1】：

我很想分享这个数据检索器（只读）层的设计。

架构的关键：

这个想法是创建一个几乎是单例的对象（如下所述），该对象用于保存使用 get 方法检索的数据 - 下面我将其称为 DRO (DataRetrieverObject)。 客户端对象应该很容易到达DRO。 应该很容易维护类。

结构基于三步构造。

使用具有（重载）静态方法的DataRetrieverFactory，每个表对应一个您需要的方法。使用重载来匹配不同类型的键。该方法将返回一个 DRO。

DataRetrieverFactory 将构造作业委托给将创建实际 DRO 的第二类 <TableNameAndKey>DR。

在<TableNameAndKey>DR 中，我们有一个指向 DRO 的静态指针列表，循环该列表以查看您是否已经拥有具有特定键的 DRO。

3.1。如果您找到 DRO - 检查它是否正常（意思是：

它不应该是“旧的”， 它应该属于会话运行， 等）

3.1.1。如果 DRO 正常，则返回 DRO。

3.1.2。如果 DRO 不正常，则删除对象（及其指针）并使用数据库中的数据创建一个新的 DRO。将指针存储在列表中。

3.2。如果指针列表中没有命中，那么我们使用数据库中的数据创建一个新的 DRO，并将指针存储到静态列表中。

使用这种技术，可以根据需要重用 DRO，但是该类不是单例的，因为我们可以拥有该类的大量实例。

【讨论】：

查看数据访问对象以了解行业标准方法。

【参考方案2】：

我发现这篇关于创建 DAL 的文章：

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

【参考方案3】：

数据访问层访问数据，仅此而已。

【参考方案4】：

.NET 的一个非常简单的示例如下。

如果有两个类： SomePage（这是一个 ASP.NET 页面） 和 DataService（这是一个普通的旧 C# 类）

如果 SomePage 总是调用 DataService 来读/写数据，那么你有一个数据访问层。 SomePage 将不包含 SQL 或对 System.Data.SqlClient 类的引用。

但 SomePage 可以使用从 DataService 类传入和传给的 DataSet 或业务对象。

【参考方案5】：

除了其他人所说的之外，我通常认为它是抽象出数据存储方式的地方。一个非常好的数据访问层应该允许您交换 Oracle、SQL Server、Access、纯文本文件、XML 或任何您想要的东西，并且这样做对其他应用程序层是透明的。换句话说，数据访问层和其他层之间的契约应该以与数据库无关的方式定义。

【参考方案6】：

大多数人认为您的同事所说的不是 DAL。 DAL 应该封装对数据库的任何调用，无论是通过动态 SQL、存储过程还是使用 IRepository 之类的 ORM 完成的。您的网页永远不应包含 SQL 或业务逻辑，否则它会成为维护的噩梦。

【讨论】：

+1 对于大部分内容。然而，动态 SQL 通常表明访问层设计不佳。

【参考方案7】：

我个人将 DAL 定义为我的应用程序和数据库之间存在交互的地方。所以我可能有一个与 DAL 交互以允许 CRUD 操作的业务层。

例如，我可能有一个 ModelClass.LoadAll() 方法可以与 DAL 交互，该方法将获取数据，而 ModelClass 将以任何需要的方式使用该数据。

我更喜欢让 DAL 尽可能轻，但其他一些人更喜欢在 DAL 中填充模型数据的另一种方式。

【讨论】：

对我来说，DAL 只是一个执行我的 CRUD 并仅连接到数据库的地方

【参考方案8】：

保存数据的“黑匣子”。如果它是用户关心/可以告诉那里有一个数据库（除了每个考虑），这不是我想要的