论DAOs的正确使用

Question

DAO是只为基本CRUD操作保留的，还是也可能包含一些复杂的搜索逻辑？

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

然而，随着应用程序变得更加复杂，出现了新的需求，例如: 1.为给定作者找到第一本书；2.查找作者在一段时间内写过的书；3.查找特定作者所写的特定主题的书。等

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

我面临这样的困境:以下方法应该去哪里:findBooks(作者) findBooks( publisher )在BookDAO中，还是在AuthorDAO中，另一个在PublisherDAO中？

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

Answer 1

DAO仅为基本CRUD操作保留吗？

不是的。可以随意地将所有数据访问逻辑放在DAOs中。

不要将DAOs与DALs混淆：

Answer 2

这些东西应该去哪儿？我现在是否为每个实体创建了一个单独的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类，并将它们放在那里？它们到底属于道层吗？

见下文。

我面临这样的困境:以下方法应该去哪里:findBooks(作者)findBooks(发布者)在BookDAO中，或者在AuthorDAO中，另一个在PublisherDAO中

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

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

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