架构 – DAL应该有多复杂?

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

你对扩展到CRUD有什么看法(我想大多数都可以):

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

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

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

先感谢您!

最佳答案 我认为它应该像你需要的那样复杂.

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

>全部查找 – 返回列表
>按主键查找
>保存(我的偏好 – 创建或更新.如果对象被标记为新,那么它是创建,否则更新)
>按对象或主键删除

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

>按名称查找
>按日期删除
等等

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

点赞