Design patterns 查询对象-哪一层？

我正在阅读这篇文章[1]，内容是关于摆脱存储库，通过使用查询对象直接使用ORM（特别是EF）

查询对象将属于洋葱架构/清洁架构的哪一层？我不知怎的觉得他们属于域核心，但想再次检查

---

[1] 在

清洁体系结构

和

洋葱体系结构

方法中，无法使用

查询对象

，因为对象是业务规则/域的一部分，而ORMs/存储库是基础设施/外部接口的一部分

看一下描述和描述。这两种方法都明确指出：业务对象独立于外部源。允许业务对象知道如何从数据库中保存/检索自身，这完全违反了前面提到的语句

顺便说一下，你链接中的文章说

我不认为在您的ORM上创建一个抽象提供了太多的价值，我也不认为如果您直接在UI层中使用您的ORM就一定不好

---

在UI层直接使用ORM是一个非常糟糕的决定，最好不要做类似的事情，并明确划分责任层。我建议您不要遵循那篇文章中的信息。

作者的论点是EF本身实现了存储库和工作单元模式，所以他声称在存储库后面进行抽象是不必要的。因此，我们不必创建一个

IRepository

并为其提供谓词和规范，而只需将

DbContext

视为存储库并直接对其进行编程（注入它、保存它、查询它）。然后，我们可以将它们放在一个类中并命名，而不必到处都有多个查询，我同意，直接将

DbContext

注入控制器是可疑的。@Robotron使用裸

DbContext

或将其隐藏在

IRepository

下是另一个问题。OP在

干净架构

或

洋葱架构

的上下文中询问。普通的三层体系结构允许就您所提到的“干净”和“洋葱”进行辩论。因为在业务层对象中直接引用EF中的任何内容都会创建依赖关系。如果我们遵循本文的逻辑，并允许

DbContext

表示存储库，那么它就可以被注入到核心中。除非您有业务需求来切换出ORMs，否则您必须将其隐藏在接口后面。