architecture - DAL 应该有多复杂？

Question

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

您如何看待以下对 CRUD 的扩展(我想大多数都可以):

阅读:GetById、GetByName、GetPaged、GetByFilter……等等。方法

创建:获取或创建 方法(模型实体从 DB 返回或创建，如果未找到并返回)，Create(lots-of-relations) 代替 Create 和多个 AssignTo 方法调用

更新:合并 方法(实体列表在一次调用中更新、创建和删除)

删除:删除 (bool children) - 可选的子项删除，清理 方法

安装方法:DAL 负责用预定义的字典实体填充空数据库

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

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

先感谢您!

Answer 1

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

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

查找所有 - 返回列表

按主键查找

保存(我的偏好——创建或更新。如果对象被标记为新的，那么它是一个创建，否则更新)

按对象或主键删除

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

按名称查找

按日期删除

等等

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