DAL有多复杂？

Question

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

你对扩展到CRUD有什么看法（我想大多数都可以）：

1. 阅读：GetById，GetByName，GetPaged，GetByFilter ... e.t.c.方法
2. 创建： GetOrCreate 方法（模型实体从DB返回或创建，如果找不到并返回），Create（lots-of-relations）而不是Create和多个AssignTo方法调用
3. 更新：合并方法（实体列表在一次通话中更新，创建和删除）
4. 删除：删除（bool children） - 可选子项删除，清理方法
5. 安装方法：DAL负责使用预定义的字典实体填充空数据库

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

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

提前谢谢！

Answer 1

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

管理这个问题最简单的方法可能是创建某种基类（取决于你的框架，可以是一个需要覆盖的方法的抽象类），它具有最基本的CRUD方法，例如，

• 查找全部 - 返回列表
• 按主键查找
• 保存（我的偏好 - 创建或更新。如果对象被标记为新，那么它是创建，否则更新）
• 按对象或主键删除

除此之外，为每个特定对象创建子类，例如

• 按名称查找
• 按日期删除
• 等。等

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

Answer 2

我不确定'复杂'是否是正确的词，它实际上取决于您定义为“业务逻辑”并确保您保持清洁Separation of Concerns。

  

阅读：GetById，GetByName，GetPaged，   GetByFilter ... e.t.c.方法

和你一样，我会把这些都称为Read，我认为它们很好（尤其是GetById）。 只要它们是以数据为中心的，你在那里看到的一些比较模糊的东西也可能很好。

RE缓存：我主要是在BL中完成的，虽然我没有看到为什么你不能在DAL中做到这一点，如果那是合适的。如果你有一堆客户端敲击数据存储库并且数据不会经常变化 - 那么肯定，为什么不呢。

RE边界：我想到了一些事情。

• 我总是在接口（）后面抽象出我的实际数据访问提供者;如果你确保这个接口是干净的依赖关系（即：它对MS SQL，Oracle，MySQL和NoSQL数据源同样有效）那么你就走在正确的轨道上 - 只要你将DAL技术特定的东西引入到接口，你知道你做错了什么（如果你在.net泛型类型，像DataTables是好的恕我直言）。
• 当你开发BL时，你应该知道应用程序的大小和可能的瓶颈;因此，你没有理由不清楚BL（和它的DAL）是如何设计的。所以，当你遇到一个你知道会被敲定的业务任务，返回大量数据等等时，我认为考虑设计能够有效处理它的方法是很好的。您可以设计一个具有“批量”和许多较小查询的界面来执行相同的操作 - 这样您就可以涵盖不同的使用情况。是的，可维护性会受到影响但是通过预先考虑一些思路/设计（有点像你需要将安全性融入应用程序 - 而不是尝试在以后添加它作为一种思考后）可以部分地减轻这种影响

最后（ imporant ） - 关于BL的事情是，虽然它经常很复杂，但它也特定于你正在处理的app / service;数据本身可以拥有自己的规则，有时这些规则最好在数据级别实施 - 而不是在单个应用程序中实施。