我检查了很多样本，但我没有找到适当的解决方案。 有些文档说“理想情况下，您的业务逻辑层不应该知道有数据库。它不应该知道连接字符串或SQL。”
我找到了一些样本，它们将业务逻辑定位到@Service注释类，但它们在@Service方法中使用SQL / HQL。
理想用法应该是什么？如果我们想要更改数据库或持久性技术，我们是否应该仅更改@Repository注释类或它们两者？
答案 0 :(得分：2)
在您的服务方法中，您不应使用任何SQL / HQL语法或任何数据库工作。所有这些都应该在DAO层中，注释为@Repository。您应该从您的服务方法中调用它们。通过这种方式，您可以在将来轻松更改数据库。否则，它会有太多的负担
答案 1 :(得分：2)
我更喜欢将所有与持久性相关的东西（即查询，以及处理JDBC，JPA或Hibernate的所有内容）放在DAO层中，并让服务层依赖此DAO层来处理与持久性相关的内容。
但主要目标是不能在不影响服务层的情况下更改持久性技术。例如，如果从Hibernate切换到JPA，那么这是可能的，例如，如果从JPA切换到JDBC，那就不可能了。原因是
因此，更改持久性技术将影响服务层，即使所有持久性内容在DAO中都是隔离的。
这种脱钩的主要优点，恕我直言
答案 2 :(得分：2)
理想情况下，您的业务逻辑处理或构建域的对象或由其组成。它不应该意识到持久性等问题。这就像O / R-Mapper就像hibernate一样。业务逻辑需要基于域属性（如员工姓名，上个月的收入......）所需的对象。
持久层应该能够将业务需求转换为SQL / HQL / Service调用或所使用的技术。因此，业务逻辑层仅在业务逻辑发生更改时才会更改。
这将是理想世界的目标，但实际上它不适用于非平凡的问题。你无法避免某种程度的耦合。但正如@JB Nizet所说，将耦合减少到合理数量是值得的。使用TDD并遵守SRP等OO原则将帮助您实现目标。