DAL 应该有多复杂？答案

【问题标题】：How sophisticated should be DAL?DAL 应该有多复杂？
【发布时间】：2011-02-25 20:08:27
【问题描述】：

基本上，DAL（数据访问层）应该提供简单的 CRUD（创建/读取/更新/删除）方法，但我总是想创建更复杂的方法，以最大限度地减少来自业务逻辑层的数据库访问往返。

您如何看待以下 CRUD 扩展（我想大部分都可以）：

您通常在哪里实现实体缓存功能？ DAL 还是 BLL？（我的选择是 BLL，但我也看到了 DAL 的实现）

当你决定的时候边界在哪里：这个操作太具体了，所以我应该在业务逻辑层中将它实现为 DAL 多次调用？我经常发现在十几次数据库往返中实现的 BLL 操作不足，因为开发人员害怕创建更复杂的 DAL。

提前感谢您！

【问题讨论】：

【解决方案1】：

我认为它应该像你需要的那样复杂。

可能最简单的管理方法是创建某种基类（取决于您的框架，可以是具有需要覆盖的方法的抽象类），其中包含最基本的 CRUD 方法，例如，

除此之外，每个特定对象的子类，例如

...但所有这些都应该是纯粹的数据访问。任何类型的业务规则执行（您通常会知道何时开始放置 if 语句和 switch 案例）应保留在业务层中。

【讨论】：

我不太喜欢只用于基本操作的基类:(因为我必须实现所有方法，最后发现有些实现从未使用过。
如果是这样，那就想想 YAGNI（你不需要它）。 YAGNI 意味着你只为你需要的东西编写，直到你必须的时候才把它抽象成某种基类。在任何情况下，当您拥有框架（例如 Hibernate/NHibernate）时，我上面的示例确实更有用，并且在 .NET 中与泛型一起使用时非常好用。如果这一切都让您感到困惑，也许您应该坚持使用存储过程？
哦，不，谢谢（仅在操作复杂且时间紧迫的情况下）:) 是的，当人们习惯于为实体实现编辑器时，我已经看到了基本类（可能是基本接口会更合适）（不同的实体，但相同的操作）。

【解决方案2】：

我不确定“复杂”是正确的词，它实际上只取决于您对“业务逻辑”的定义以及确保您保持干净Separation of Concerns。

读取：GetById、GetByName、GetPaged、 GetByFilter...等。方法

和你一样，我将这些都称为 Read，我认为它们很好（特别是 GetById）。只要它们以数据为中心，您所拥有的一些比较模糊的可能也可以。

RE 缓存：我主要在 BL 中完成了它，尽管如果这适当，我看不出有什么理由不能在 DAL 中执行它。如果您有一堆客户冲击数据存储库并且数据不会经常更改 - 那么当然，为什么不呢。

RE Boundary：我想到了几件事。

我总是在接口 () 后面抽象出我的实际数据访问提供者；如果您确保此接口没有依赖关系（即：它同样适用于 MS SQL、Oracle、MySQL 和 NoSQL 数据源），那么您就在正确的轨道上——只要您将任何特定于 DAL 技术的东西引入接口，你知道你做错了什么（如果你在 .net 泛型类型中，比如 DataTables 很好，恕我直言）。
在开发 BL 时，您应该对应用程序的大小和可能的瓶颈有所了解；因此，没有理由不知道 BL（以及它是 DAL）的设计方式。因此，当您遇到一个您知道会受到重创的业务任务时，返回大量数据等，我认为考虑设计以有效方式解决它的方法是很好的。您可以设计一个包含“批量”和许多执行相同操作的较小查询的界面 - 这样您就可以涵盖不同的使用案例。是的，可维护性会受到影响，但通过预先考虑/设计可以部分缓解（有点像您需要将安全性融入应用程序 - 而不是稍后尝试添加它作为事后的想法） .

最后（重要） - 关于 BL 的问题在于，虽然它通常很复杂，但它也特定于您正在开发的应用程序/服务；数据本身可以有自己的规则，有时最好在数据级别执行这些规则，而不是在单个应用程序中。

【讨论】：