存储库和使用原始sql查询？

Question

我正在努力了解如何最好地查询存储库.

现在让我通过循环的三个因素是:

第1点

关于问题一:

我有很多方法的存储库返回实体和标量值的组合.这似乎导致"方法爆炸".我应该总是返回一个Entity对象吗？我该如何查询只需要一列的对象？

第2点 当运行查询时,我是否应该包括表中的每一列,即使我只需要一列或两列？如果我为此创建特定查询,则会导致存储库中有更多方法

第3点 我应该如何为查询提供条件？我读到了有关规范的内容,但我的理解是您遍历返回的记录并过滤掉传入新集合的记录.这似乎不是一个明智的表现.现在我只是在Repo中创建一个新方法,如getNameById(),它封装了条件.

请注意,我没有使用ORM,我只是在我的存储库中有原始sql.

更新

第1点: 根据答案和更多的研究,这将是一个很好的实施？

现在我有一个大型存储库,它返回标量和实体类型对象的混合(所有相同的实体).我想如果我只使用GetUser(userId)方法并忘记编写只返回单列值的方法,我可以大大减少这个.

例如,如果我需要返回一个用户名,我可以调用GetUser(userId)方法来润滑User对象,然后在服务层中将其过滤到用户名.

另一种方法是使用某种我可以传递到Repository的QueryBuilder类,可以解析它以生成正确的sql.

第2点

回顾这一点非常类似于第一点,我目前的解决方案是只获取所有表字段.这是性能和可维护性之间的权衡.

第3点

我需要提供某种where子句.我不确定这是否有意义通过规范或只是一个SQL字符串.我目前的解决方案是为这些类型创建新的方法,但我想要一些更通用的存储库

总的来说,仍然在研究这个......我希望能够听到更多关于这一点的信息,或者链接到书籍或参考文献,将这一切联系在一起.

Answer 1

我的存储库包含许多方法，这些方法返回实体和标量值的组合。这似乎导致了“方法爆炸”。我应该总是返回一个实体对象吗？我应该如何查询只需要一列的对象？

您可以像对抗其他 SRP 违规一样对抗存储库方法爆炸。您可以为同一实体创建另一个存储库。请参阅类似问题的答案。

运行查询时，即使我只需要一列或两列，我是否应该包含表中的每一列？如果我为此创建特定查询，它将导致存储库中出现更多方法

这不是一个 DDD 问题。领域驱动设计不处理“行和列”。加载多少数据来“补充”域对象总是存在一些冗余，但您必须衡量这是否真的会影响您的性能。如果这确实是性能瓶颈，那么它可能是域模型不正确的症状。

我该如何提供查询条件？我阅读了有关规范的内容，但我的理解是循环返回的记录并过滤掉传递到新集合中的记录。从性能角度来看，这似乎不是一个好主意。现在我只是在 Repo 中创建一个新方法，例如 getNameById() ，它封装了条件。

这又是一个数据访问问题。DDD 中没有任何内容表明您的存储库无法将规范转换为 SQL 查询。是否执行此操作或迭代内存中的记录取决于您（只要存储库使用者仅看到规范和存储库并且不知道实际实现）。

关于“Draw SQL vs. DDD 中的 ORM”，您可能会发现这个答案很有趣。