定义数据访问层

Question

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

所以，我把问题抛出去了。您将如何定义数据访问层？

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

EG我可能有一个与DAL交互的ModelClass.LoadAll（）方法，它将获取数据，而ModelClass将以任何所需的方式使用该数据。

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

Answer 6

数据访问层访问数据，没有别的。

Answer 7

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

Answer 8

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

架构的关键：

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

该结构基于三步结构。

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

2. DataRetrieverFactory将施工作业委托给将创建实际DRO的第二个班级<TableNameAndKey>DR。

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

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

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

   3.1.1。如果DRO没问题 - 那么返回DRO。

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

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

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