关于正确使用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中。

请勿将DAO与DAL s混淆：

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（作者作者）findBooks（出版商出版商）既可以在BookDAO中，也可以在AuthorDAO中，另一个是PublisherDAO

  

这取决于我认为这不是企业软件架构的问题，而是OOD。随着您的逻辑变得越来越复杂，您必须牢记增加内聚力并减少软件组件之间的耦合，并分别从这些被认为属于的方法中提取新类（重构目录http://martinfowler.com/refactoring/catalog/extractClass.html中的Extact类）相同的业务环境，如AuthorDAO，关于作者功能的所有方法和所有图书调用的书籍，以便使您的代码更具可读性，可重用性，可测试性，可维护性......

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

  

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