关于 DAO 的正确使用

Question

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

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

但是，随着应用变得越来越复杂，出现了新的要求，例如： 1. 找到给定作者的第一本书 2.查找作者在一段时间内写过的书 3. 查找给定作者写的关于特定主题的书籍 4. ....等

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

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

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

Answer 1

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

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

不要将DAOs 与DALs 混淆：

Answer 2

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

绝对是 DAO（层）的工作和要求。你所拥有的一切都无关紧要。具体方法应该去它所属的DAO。

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

这里有两件事。

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

Answer 3

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

见下文。

我有这个困境：以下方法应该去哪里： findBooks(Author author) findBooks(Publisher publisher) 都在BookDAO中，或者一个在AuthorDAO中，另一个在PublisherDAO中

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

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

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