关于 DAO 的正确使用

Question

DAO 是否只保留用于基本的 CRUD 操作，或者它还可以包含一些复杂的搜索逻辑？

想象一下两个实体类 Book 和 Author 以及它们之间的多对多关系。此时，单个 DAO 就足够了，因为两个实体的基本 CRUD 操作是相同的。

然而，随着应用程序变得越来越复杂，新的要求就会出现，例如： 1. 查找给定作者的第一本书 2.查找某个作者在一段时间内写过的书 3. 查找特定作者所写的特定主题的书籍 4. ....等等

所有这些应该去哪里？我现在是否为每个实体创建一个单独的 DAO 类，并将它们放在那里？它们到底属于 DAO 层吗？

我有这样的困境： 以下方法应该放在哪里： 查找书籍(作者作者) findBooks（出版商出版商） 两者都在 BookDAO 中，还是一个在 AuthorDAO 中，另一个在 PublisherDAO 中？

或者也许我应该考虑一个全新的抽象，它位于 DAO 之上，并将它们留给基本的 CRUD 操作 - 例如 SearchService，它列出了所有可能的搜索？

Answer 1

DAO 是否只保留用于基本的 CRUD 操作

否。请随意将所有数据访问逻辑放在 DAO 中。

不要将 DAO 与 DAL：

Answer 2

这些应该去哪里？我现在是否为每个实体创建一个单独的 DAO 类，并将它们放在那里？它们到底属于 DAO 层吗？

这绝对是 DAO（层）的工作和要求。你所拥有的一切并不重要。具体方法去它所属的DAO中。

或者也许我应该考虑一个全新的抽象，它位于 DAO 之上，并将它们留给基本的 CRUD 操作 - 例如 SearchService，它列出了所有可能的搜索？

这里有两件事。

1. 看起来您正在使用 Hibernate 或某些 ORM 工具。因此我相信你有合适的对象。您可以在 DAO 层中使用这些对象而不是 Map、List 或 Primitives，没有任何问题。无论如何，在不偏离DAO层的情况下，你仍然可以在这里拥有DAO层。并根据需要验证业务规则。
2. 看起来你的意思是 AbstractDAO 模式（搜索/谷歌相同），Hibernate 和 Spring 也提供了这样的东西。 Spring 也为此提供了一种 SearchService 类型的工具（实际上是类）。

Answer 3

这些都应该去哪里呢？我现在是否为每个实体创建一个单独的 DAO 类，并将它们放在那里？它们到底属于 DAO 层吗？

见下文。

我遇到了这样的困境：以下方法应该去哪里： findBooks(Author 作者) findBooks(Publisher 出版商) 都在 BookDAO 中，或者一个在 AuthorDAO 中，另一个在 PublisherDAO 中

这要看情况，我认为这不是企业软件架构的问题，而是 OOD 的问题。当你的逻辑变得复杂时，你必须记住增加软件组件之间的内聚性并减少耦合，并分别从重构目录中提取一个新类（Extact Class from Refactoring Catalog http://martinfowler.com/refactoring/catalog/extractClass.html) 与这些方法被认为属于同一业务上下文，例如 AuthorDAO 用于所有有关 Author 功能的方法和 Books 用于所有 Books 调用，等等，以使您的代码更具可读性、可重用性、可测试性、可维护性……

或者也许我应该考虑一个全新的抽象，它位于顶部DAO 并将它们留给基本的 CRUD 操作 - 例如 SearchService，它列出了所有可能的搜索？

如果您指的是业务逻辑，则该抽象存在于多层模型中，称为业务层。
您可以将业务逻辑与业务对象相关联。但是 findXXX 方法属于位于持久层和业务层之间的 DAO。