定义数据访问层
似乎每个人都知道 GUI、业务逻辑和数据访问之间应该有明确的区别。 我最近与一位程序员交谈，他吹嘘自己始终拥有干净的数据访问层。 我查看了这段代码，发现他的数据访问层只是一个封装了一些 SQL 方法（如 ExecuteNonQuery 和 ExecuteReader）的小类。 事实证明，在他的 ASP.NET 页面隐藏代码中，他将大量 SQL 硬编码到 page_load 和其他事件中。 但他发誓他正在使用数据访问层。
所以，我把这个问题扔掉。 您将如何定义数据访问层？
It seems that everybody knows you're supposed to have a clear distinction between the GUI, the business logic, and the data access. I recently talked to a programmer who bragged about always having a clean data access layer. I looked at this code, and it turns out his data access layer is just a small class wrapping a few SQL methods (like ExecuteNonQuery and ExecuteReader). It turns out that in his ASP.NET code behind pages, he has tons of SQL hard coded into the page_load and other events. But he swears he's using a data access layer.
So, I throw the question out. How would you define a data access layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
你的同事所说的并不是大多数人认为的 DAL。 DAL 应该封装对数据库的任何调用，无论是通过动态 SQL、存储过程还是使用 IRepository 之类的 ORM 来完成。 您的网页永远不应该包含 SQL 或业务逻辑，否则它会成为维护的噩梦。
What your colleague is talking about is not a DAL by most peoples reckoning. The DAL should encapsulate any calls to the database whether done by dynamic SQL, stored procs or an ORM with something like IRepository. Your web pages never should contain SQL or business logic or else it becomes maintenance nightmare.
.NET 的一个非常简单的示例如下。
如果有两个类：
SomePage（这是一个 ASP.NET 页面）
和
DataService（这是一个普通的旧 C# 类）
如果 SomePage 始终调用 DataService 来读取/写入数据，那么您就有了一个数据访问层。 SomePage 将不包含 SQL 或对 System.Data.SqlClient 类的引用。
但 SomePage 可以使用 DataSet 或从 DataService 类传递到 DataService 类的业务对象。
A very simple example for .NET would be as follows.
If have two classes:
SomePage (which is an ASP.NET Page)
and
DataService (which is a plain old C# class)
If SomePage always calls to DataService to read/write data then you have a Data Access layer. SomePage will contain no SQL or references to System.Data.SqlClient classes.
But SomePage can use DataSets or business objects that are passed from and to the DataService class.
除了其他人所说的之外，我通常认为它是抽象出数据存储方式的地方。 一个真正好的数据访问层应该允许您替换 Oracle、SQL Server、Access、平面文本文件、XML 或您想要的任何内容，并且这样做对于其他应用程序层来说是透明的。 换句话说，数据访问层和其他层之间的契约应该以与数据库无关的方式定义。
In addition to what the others have said, I usually consider it the place to abstract out how your data is being stored. A really good data access layer should allow you to swap out Oracle, SQL Server, Access, a flat text file, XML, or whatever you want, and doing so would be transparent to the other application layers. In other words, the contract between the data access layer and other layers should be defined in a database agnostic way.
我个人将 DAL 定义为应用程序和数据库之间存在交互的地方。 因此，我可能有一个与 DAL 交互的业务层以允许 CRUD 操作。
EG 我可能有一个 ModelClass.LoadAll() 方法，它可以与 DAL 交互，该方法将获取数据，并且 ModelClass 将以任何需要的方式使用该数据。
我更喜欢让 DAL 尽可能轻，但其他一些人更喜欢在 DAL 中填充模型数据的另一种方式。
I personally define the DAL as where the interactions between my application and the database exist. So I may have a Business Layer that interacts with the DAL to allow CRUD operations.
EG I may have a ModelClass.LoadAll() method that would interact with the DAL, which would fetch the data and the ModelClass would use that data in whatever way it needed.
I prefer to keep the DAL as light as possible, but some other people prefer the other way where the populating of the Model Data happens in the DAL.
数据访问层访问数据，仅访问其他内容。
A data access layer accesses data, and nothing else.
保存您的数据的“黑匣子”。 如果用户关心/可以知道那里有一个数据库（除了考虑因素之外），那么这并不完全是我想要的
A "Black box" that holds your data. If it's user cares/can tell that there is a DB back there (aside from per consideration), it's not quite what I'm thinking of
我很乐意分享这个数据检索器（只读）层的设计。
架构的关键：
DRO(DataRetrieverObject）。DRO。该结构基于三步构造。
使用具有（重载）静态方法的
DataRetrieverFactory，每个表对应一个您需要的静态方法。 使用重载来匹配不同类型的键。 该方法将返回一个 DRO。DataRetrieverFactory将构造作业委托给第二个类DR 在
DR 3.1。 如果您找到 DRO - 检查它是否正常（意思是：
3.1.1。 如果 DRO 正常 - 则返回 DRO。
3.1.2。 如果 DRO 不正常，则删除该对象（及其指针）并使用数据库中的数据创建一个新的 DRO。 将指针存储在列表中。
3.2。 如果指针列表中没有命中，则我们使用数据库中的数据创建一个新的 DRO，并将指针存储到静态列表中。
使用这种技术，我们可以根据需要重用 DRO，但是该类不是单例的，因为我们可以拥有该类的大量实例。
I would love to share this design of data retriever (read-only) layer.
Keys for the architecture:
DRO(DataRetrieverObject).DRO.The structure is based on a three-step construction.
Use a
DataRetrieverFactoryhaving (overloaded) static methods, one for each table you need. Use the overloading to match different kind of keys. The method will return a DRO.The
DataRetrieverFactorydelegate the construction job to a second class<TableNameAndKey>DRthat will create the actual DRO.In the
<TableNameAndKey>DRwe have a static list of pointers to DRO's, loop the list in order to see if you already have a DRO with the specific key.3.1. If you find a DRO - check if it is ok (meaning:
3.1.1. If the DRO is OK - then return the DRO.
3.1.2. If the DRO is not OK then delete the object (and its pointer) and create a new DRO with data from the database. Store the pointer in the list.
3.2. If there is not hit in the list of pointers, then we create a new DRO with data from the DB, and store the pointer into the static list.
Using this technique one may reuse the DRO depending on the need, however the class is not singleton since we are allowed to have plenty of instances of the class.