查询对象——哪一层？答案

【问题标题】：Query objects - which layer?查询对象——哪一层？
【发布时间】：2020-06-03 07:54:10
【问题描述】：

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

Query 对象属于 Onion 架构/Clean 架构的哪一层？我不知何故觉得它们属于域核心，但想仔细检查一下。

【问题讨论】：

【解决方案1】：

在Clean Architecture 和Onion Architecture 方法中，无法使用Query objects，因为对象是业务规则/域的一部分，而ORM/存储库是基础架构/外部接口的一部分。

查看Onion Architecture 描述和Clean Architecture 描述。两种方法都清楚地表明：业务对象独立于外部资源。允许业务对象知道如何从数据库中保存/检索自己是直接违反上述声明的。

顺便说一句，您链接中的文章说

我不认为在你的 ORM 上创建一个抽象提供了很多价值，我认为如果你直接在 UI 层中使用你的 ORM 也不一定是坏事。

直接在 UI 层使用 ORM 是一个非常糟糕的决定，最好永远不要做这样的事情，并清楚地划分责任层。我建议你不要关注那篇文章中的信息。

【讨论】：

作者的论点是 EF 本身实现了存储库和工作单元模式，因此他声称在存储库后面进行抽象是不必要的。因此，与其创建IRepository<T> 并为其提供谓词和规范，我们可以将DbContext 视为存储库并直接对其进行编程（注入、保存、查询）。
然后，我们可以将它们放在一个类中并命名它们，而不是到处进行多个查询，从而遵循 SOLID 的逻辑结论。
将DbContext 直接注入控制器是可疑的，我同意。
@Robotron 使用裸DbContext 或将其隐藏在IRepository<T> 下是另一个问题。 OP 在Clean Architecture 或Onion Architecture 的上下文中询问。普通的 3 层架构允许就您提到的内容进行辩论，“干净”和“洋葱”则不允许。因为直接在业务层对象中引用 EF 中的任何内容都会创建依赖关系。
如果我们按照文章的逻辑，允许DbContext代表存储库，那么它就可以被注入核心。除非您有切换 ORM 的业务需求，否则您必须将其隐藏在接口后面。