我应该在哪里实现mvc架构（Spring hiberNate）中的特定查询？

Question

我正在使用Spring mvc和hibernate实现一个企业应用程序。应用程序体系结构由以下层组成：

• 查看
• 控制器
• 服务
• 域
• Peristence公司

数据访问是使用经典的 dao 模式实现的，并允许 CRUD 操作泛型查询。我应该在哪里实现特定查询？我想有两种解决方案：

• 通过创建Hibernate条件并将其传递给持久层来实现服务层中的特定查询
• 通过为每个查询创建一个函数并调用服务层中的函数来实现DAO类中的特定查询。

我该怎么办？有更好的解决方案吗？

Answer 1

这个：

• 通过为每个查询创建一个函数并调用服务层中的函数来实现DAO类中的特定查询。

DAO 是“数据访问对象”的简写，使用 DAO 模式的不良原因之一是遵守“单一责任原则”。如果你的代码中还有其他一些类，除了处理数据访问的DAO类之外，那么你就违反了SRP，使用DAO模式或多或少成为一个有争议的问题。

更重要的是，出于可维护性的目的，如果其他开发人员稍后要维护您的代码，并且他们看到一堆DAO类，他们不会期望数据访问发生在其他任何地方。

您的服务层甚至不应该依赖于 Hibernate。你为什么会这样？你的服务层应该只依赖于你的域层，而域层又取决于你的持久层，这是你的Hibernate依赖应该在哪里，

Answer 2

从分层架构的角度来看，sql查询不应该在DAO层之外使用/声明。您可能已经注意到，spring选择在服务层使用事务，因为事务不是DAO的责任，您也可以将其称为资源泄漏/横切关注点。在Dao之外声明/使用sql查询将被认为是资源泄漏/横切关注点。

自从您触摸Hibernate和标准 API 以来，我想添加一些东西。当您使用条件时，为什么需要单独的查询？标准 API 是实现持久性的一种优雅方式，因为它是完美的 OO 方法。

Answer 3

服务层是业务层，不能使用任何持久性提供程序相关的接口和类（即Hibernate Criteria API）。这是一个很好的实践——您可以在不接触服务层中的任何代码行的情况下更改持久性提供程序。

不要犹豫，选择你的第二个选项（在 DAO 类中实现特定的查询）。

或者，您可以使用一种业务动态查询模式，它是查询和构建器模式的混合（如CriteriaAPI）。下面是一个简单的例子：

interface CarQuery {
    CarQuery model(String model);
    CarQuery color(String color);
    List<CarQuery> execute(); 
}
....
List<Car> cars = carDao.getQuery().model("Jeep").color("green").execute();
....

您可以在内部实现HibernateCarQuery，它可以使用HiberNate标准API。这肯定需要一些额外的努力，但如果您计划广泛使用特定方法并需要动态构建查询的能力，则不会用特定方法污染您的daos（典型情况是UI页面上的多个过滤器）。