java - 访问数据库时分离关注点的最佳实践

Question

当涉及访问数据库(通过 Hibernate)的应用程序时，我一直在尝试改进关注点分离。

在其中一个应用程序中，我一直在使用以下方法:

• 使用不连接/不了解数据库的业务逻辑创建服务。他们只与 GeneralDAO(以及其他服务)通信；
• 负责 CRUD/查找操作的 GeneralDAO，以及涉及更复杂数据库查询的方法。

我发现这种方法存在的问题是:

• 当您的应用程序增长并需要大量特定的数据库查询时，GeneralDAO 慢慢成为上帝对象。
• 有时，更具体的服务仅成为 GeneralDAO 的代理，因为该方法很简单，只需要数据库查询。参见示例 1。

示例 1:服务只是一个代理

BookService 管理图书馆应用程序中与书籍相关的事情。让我们考虑两种方法:

• archiveBook(书籍)
• findByIsbn(字符串 isbn)

在 archiveBook(Book) 中可能涉及相当多的业务逻辑 - 我们可以想象这涉及调用:

 distributionService.unbox(Book);
 archivalBook.archive(Book);
 librarianService.informNewBook(Book);

但是 findByIsbn(String isbn) 要简单得多:它只需要对数据库执行 SQL 调用。所以在这种情况下，我看到两个选项:

1. 将调用重定向到一个可以与数据库对话以执行查询的对象。例如 generalDAO.findByIsbn(String isbn)，它使用数据库通信层(在 Hibernate 中它将使用 sessionFactory 或 EntityManager)来执行查询。
2. 让 BookService 可以使用该数据库层，以便它自己执行查询

问题/意见(第一个数字表示上面的选项):

1.1。有 2 个方法具有完全相同的签名是不是很奇怪，即使这样做是为了使 BookService 独立于数据库层(和 ORM)？

1.2。你如何建议避免上帝反模式？您是否建议根据方法的作用将 GeneralDAO 分成几个 DAO？在这种情况下，我们是否需要冒着需要将大量 DAO 注入(inject)某些服务的风险，从而导致服务中注入(inject)了太多对象？

2.1 您如何看待这个替代方案？它不是通过让 BookService 了解两个不同抽象级别(DAO 和 sessionFactory/EntityManager)的对象来打破“关注点分离”吗？

3.1。您会建议任何其他方法/模式/最佳实践吗？

谢谢!

Answer 1

1.2. How do you suggest avoiding The God anti-pattern? Would you suggest breaking the GeneralDAO into several DAOs depending on what the methods do? In this case, won't we risk needing to inject lots of DAOs into some Services, leading to a Service having too many objects injected into it?

一般来说，一个DAO类应该处理一个特定的实体。
如果您的一个实体需要多种查询，您可以按照您所说的按共同关注点(例如:读、写、选择聚合等)对它们进行分组，将其再次划分为两个或更多 DAO。
如果你有太多的查询和太多的 DAO，也许，你应该检查一下你是否没有用几种方法编写几乎相同的查询。在这种情况下，使用规范或 Criteria API 允许客户端通过参数自定义查询。如果查询真的不同，你有不同的处理。因此，使用多个 DAO 似乎是一个合适的解决方案。它避免了增加复杂性和上帝对象的兴起。

1.1. Isn't it strange to have 2 methods with the exact same signature, even if this is done to keep the BookService independent of the database layer (and ORM)?

当您将应用划分为逻辑层时，正如您所注意到的，在某些操作中，某些层仅执行对下层的委托(delegate)调用。
所以在这些情况下，方法名相同是很常见的。我会更进一步:如果只是委托(delegate)调用，使用相同的名称是一种很好的做法。如果它们都满足相同的需求，为什么我们要在传达的行为中创建变体？

2.1 What do you think of this alternative? Doesn't it break the "separation of concerns" by having the BookService be aware of objects at two different levels of abstraction (the DAO and the sessionFactory/EntityManager)?

BookService 依赖于 DAO，但不应依赖于构成 DAO 实现一部分的 sessionFactory/EntityManager。
BookService 调用使用 sessionFactory/EntityManager 的 DAO。
如有必要，BookService 可以在其自身或其带有@Transactional 注释的方法上指定交易细节。

3.1. Would you suggest any other approach/pattern/best practice?

• 当您使用 Spring 时，请尝试依赖 Sping JPA 存储库(处理常见情况和可扩展类的样板更少)
• 当您有一些查询的多个变体时，使用规范或标准模式。