似乎每个人都知道您应该清楚地区分 GUI、业务逻辑和数据访问。我最近与一位吹嘘始终拥有干净的数据访问层的程序员交谈。我查看了这段代码，结果发现他的数据访问层只是一个包含一些 SQL 方法（如 ExecuteNonQuery 和 ExecuteReader）的小类。事实证明，在他的页面背后的 ASP.NET 代码中，他有大量的 SQL 硬编码到 page_load 和其他事件中。但他发誓他正在使用数据访问层。
所以，我抛出这个问题。您将如何定义数据访问层？
Jim
问问题
4407 次
8 回答
9
大多数人认为你的同事所说的不是 DAL。DAL 应该封装对数据库的任何调用，无论是通过动态 SQL、存储过程还是使用 IRepository 之类的 ORM 完成的。您的网页永远不应该包含 SQL 或业务逻辑，否则它将成为维护的噩梦。
于 2008-11-12T00:44:26.497 回答
5
.NET 的一个非常简单的示例如下。
如果有两个类：SomePage（这是一个 ASP.NET 页面）和 DataService（这是一个普通的旧 C# 类）
如果 SomePage 总是调用 DataService 来读取/写入数据，那么您有一个数据访问层。SomePage 将不包含 SQL 或对 System.Data.SqlClient 类的引用。
但 SomePage 可以使用从 DataService 类传入和传给 DataService 类的 DataSet 或业务对象。
于 2008-11-12T01:38:59.787 回答
3
我发现这篇关于创建 DAL 的文章：
于 2010-08-10T14:36:53.003 回答
2
除了其他人所说的之外，我通常认为它是抽象出数据存储方式的地方。一个非常好的数据访问层应该允许您交换 Oracle、SQL Server、Access、纯文本文件、XML 或任何您想要的东西，并且这样做对其他应用程序层是透明的。换句话说，数据访问层和其他层之间的契约应该以与数据库无关的方式定义。
于 2008-11-12T01:01:06.820 回答
1
我个人将 DAL 定义为我的应用程序和数据库之间存在交互的地方。所以我可能有一个与 DAL 交互以允许 CRUD 操作的业务层。
例如，我可能有一个与 DAL 交互的 ModelClass.LoadAll() 方法，该方法将获取数据，而 ModelClass 将以任何需要的方式使用该数据。
我更喜欢让 DAL 尽可能轻，但其他一些人更喜欢在 DAL 中填充模型数据的另一种方式。
于 2008-11-12T00:36:55.887 回答
1
数据访问层访问数据，仅此而已。
于 2008-12-04T06:41:35.373 回答
0
保存您的数据的“黑匣子”。如果它是用户关心/可以告诉那里有一个数据库（除了每个考虑），这不是我想要的
于 2008-11-12T00:34:42.413 回答
0
我很乐意分享这种数据检索器（只读）层的设计。
架构的关键：
- 这个想法是创建一个几乎是单例的对象（如下所述），该对象用于保存使用 get 方法检索的数据 - 下面我将其称为
DRO(DataRetrieverObject)。 - 客户端对象应该很容易到达
DRO. - 维护类应该很容易。
该结构基于三步构造。
使用
DataRetrieverFactory具有（重载）静态方法，一个用于您需要的每个表。使用重载来匹配不同类型的键。该方法将返回一个 DRO。将
DataRetrieverFactory施工作业委托给<TableNameAndKey>DR将创建实际 DRO 的第二类。在
<TableNameAndKey>DR我们有一个指向 DRO 的静态指针列表中，循环该列表以查看您是否已经有一个具有特定键的 DRO。3.1。如果您找到 DRO - 检查它是否正常（意思是：
- 它不应该是“旧的”，
- 它应该属于会话运行，
- ETC。）
3.1.1。如果 DRO 正常，则返回 DRO。
3.1.2。如果 DRO 不正常，则删除对象（及其指针）并使用数据库中的数据创建一个新的 DRO。将指针存储在列表中。
3.2. 如果指针列表中没有命中，那么我们使用数据库中的数据创建一个新的 DRO，并将指针存储到静态列表中。
使用这种技术，可以根据需要重用 DRO，但是该类不是单例的，因为我们可以拥有该类的大量实例。
于 2012-04-10T12:03:45.813 回答