我正在使用 Java EE 6 开发 Web 应用程序。为了最大限度地减少对数据库的调用，最好有类：
数据访问类 (DAO) 将仅调用基本方法 getAllClients, getAllProducts, getAllOrders, delete, update 方法 - CRUD 方法。
将调用 CRUD 方法的服务类，但另外还有过滤器方法，例如findClientByName, findProuctByType, findProductByYear, findOrderFullyPaid/NotPaid 等...这将基于基本的 DAO 方法。
谢谢
【问题讨论】：
根据我的经验（尽管有限）DAO 类往往具有允许应用程序执行的所有可能的数据库操作。所以在你的情况下，它会有getAllClients()和getClientByName(String name)等方法。
在您的 DAO 中获取所有用户并对其进行迭代，直到找到您需要的用户，这将导致不必要的计算时间和内存消耗浪费。
如果你想减少你的数据库被命中的次数，你也许可以实现一些缓存机制。 ORM 框架，例如 Hibernate 应该能够提供您所需要的，如 here 所示。
编辑：
根据您的评论问题，不，您的服务不会变得多余。所做的是通常使用Service 层来公开DAO 功能。这基本上不会使DAO 从应用程序的前端可见。它通常还允许使用额外的方法，例如public String getUserFormatted(String userName)。这将利用DAO 提供的getUserByName 功能，但提供了一些额外的功能。
Service 层也会在规范发生变化时发挥作用，并且您现在还需要一个 Web 服务来与您的应用程序交互。中间有一个服务层将允许 Web 服务通过Service 层查询DAO。
所以基本上，DAO 层仍然担心数据库内容（CRUD 操作），而服务将调整 DAO 返回的数据而不暴露 DAO。
【讨论】：
in the service you will have methods to construct the DAO. 应该是 in the service you will have methods to construct the report.
如果没有更多信息，很难说，但我认为更多地利用您的数据库可能是一个好主意，而不仅仅是 CRUD 操作。数据库擅长搜索，前提是您正确配置它们，因此恕我直言，让您的数据库为您处理 find 方法中的搜索是个好主意。这意味着您的 find 方法可能会进入您的 DAO...
最好考虑/了解数据库访问对性能的影响，但不要过火。此外，您的方法意味着，由于您的服务将进行过滤，因此您将在应用程序中加载大量数据库数据，这是一个坏主意。最重要的是，您应该按照预期使用 RDBMS，并在可能显示其存在问题时担心由于过度访问而导致的性能。我怀疑你会遇到这种情况。
【讨论】：
我会说你最好让你的 DAO 比你指定的更细。
我建议以某种方式将 findClientByName、findProuctByType、findProductByYear、findOrderFullyPaid/NotPaid 放在您的 DAO 中，因为您的数据库很可能比内存中的代码更擅长过滤和排序数据。
假设您有 10 年的数据，您在服务类上调用 findProductsByYear，然后它调用 getAllProducts，然后丢弃内存中 9 年的数据。你最好让你的数据库只返回你感兴趣的那一年。
【讨论】：
是的，这是正确的做法。
服务将拥有交易。你应该把它们写成 POJO；这样您就可以将它们公开为 SOAO 或 REST Web 服务、EJB 或您以后想要的任何其他内容。
【讨论】：