DAO和服务层设计

Question

我正在使用Java EE 6开发Web应用程序。为了最大限度地减少对数据库的调用，最好有一个类：

数据访问类（DAO）将仅调用基本方法getAllClients, getAllProducts, getAllOrders, delete, update方法 - CRUD方法。

服务类，它将调用CRUD方法，但另外还有过滤方法，例如： findClientByName, findProuctByType, findProductByYear, findOrderFullyPaid/NotPaid等等......将基于基本的DAO方法。

谢谢

Answer 1

根据我的经验（尽管有限）DAO类往往具有允许应用程序执行的所有可能的数据库操作。因此，在您的情况下，它会使用getAllClients()和getClientByName(String name)等方法。

获取DAO中的所有用户并遍历它们直到找到所需的用户将导致不必要的浪费计算时间和内存消耗。

如果您希望减少数据库被击中的次数，可以实现一些缓存机制。 ORM这样的Hibernate框架应该能够提供您所需的内容here。

编辑：

根据您的评论问题，不，您的服务不会变得多余。通常使用Service图层来公开DAO功能。这基本上不会使DAO从应用程序的前端可见。它通常还允许使用额外的方法，例如public String getUserFormatted(String userName)。这将使用getUserByName提供的DAO函数，但提供一些额外的功能。

如果规范发生变化，Service图层也会变得有用，您现在还需要一个Web服务来与您的应用程序进行交互。介于两者之间的服务层将允许Web服务通过DAO层查询Service。

所以基本上，DAO层仍然会担心关于数据库内容（CRUD操作），而服务将调整DAO返回的数据而不暴露DAO

Answer 2

如果没有更多信息，很难说，但我认为利用您的数据库而不仅仅是CRUD操作可能是一个好主意。数据库在搜索时很好，只要你正确配置它们，所以恕我直言，让你的数据库为你的find方法处理搜索是个好主意。这意味着您的查找方法可能会在您的DAO中...

考虑/了解数据库访问对性能的影响是很好的，但不要过分夸大。此外，您的方法意味着，由于您的服务将要进行过滤，您将在应用程序中加载大量数据库数据，这是一个坏主意。最重要的是你应该使用你想要使用的RDBMS，并且当你可以显示它的问题时担心由于过度访问而导致的性能。我怀疑你会遇到那种情况。

Answer 3

我会说你最好让你的DAO比你指定的更精细。

我建议在你的DAO上放置findClientByName，findProuctByType，findProductByYear，findOrderFullyPaid / NotPaid，因为你的数据库很可能比你的内存代码更好地过滤和排序数据。

想象一下，你有10年的数据，你在服务类上调用了findProductsByYear，然后调用了getAllProducts，然后在内存中丢弃了9年的数据。让你的数据库只回到你感兴趣的那一年，你会好得多。

Answer 4

是的，这是正确的方法。

该服务将拥有交易。你应该把它们写成POJO;这样，您就可以将它们公开为SOAO或REST Web服务，EJB或您以后想要的任何其他内容。