我应该在MVC架构中使用Hibernate Criteria？

2023年10月22日 225次阅读

我正在开发一个使用
Spring MVC和Hibernate的CRM项目,我不知道什么是使用hibernate标准的最佳位置.我想使用hibernate标准,因为我们在表示层上具有搜索功能,用户可以通过不同方式基于各种参数进行搜索.有时我们只需要ID,有时我们需要属性的子集,有时我们需要连接多个表,等等.因此,构建一个结构化的标准,如hibernate的标准,而不是从表示中传递参数,订单,所需参数和搜索限制的列表层到数据层,可以清理代码.但是,我知道在表示层使用hibernate是不正确的,因为它违反了MVC架构.我真的不认为重复hibernate的标准是正确的方法.我可以想到3种方法：

>在业务层中创建十二种方法,每种方法针对每种类型的搜索请求,并根据情况从表示层调用这些功能.这些方法中的每一种基本上都不做任何事情,只是将参数传递给相应的DAO方法,该方法将创建SQL查询(或条件对象)并从数据库中检索数据.在这种方法中,我最终会得到数百种方法,这些方法除了将参数传递给DAO之外什么都不做.
>在演示文稿(或业务层)中创建类似于Hibernate的Criteria类的类.然后使用表示层中的搜索参数启动此对象并将其传递给DAO.然后,DAO基于此对象创建一个hibernate的条件对象.这种方法涉及复制hibernate的标准类.
>在表示层中启动Hibernate的Criteria类,并将其传递给DAO以获取搜索结果.

能告诉我哪一个是最好的方法吗？

谢谢

最佳答案 我认为最好的选择取决于您的查询要求.

如果可能的话,我建议你去寻找第一个选择.我经常发现自己实现了DAO搜索方法,它采用了很多可以为空的参数.如果相应的方法参数未设置为NULL,则DAO方法本身会构建添加约束的条件对象.

这是一个简单的例子：

public List<SomeObject> findSomeObjects(String name, Integer categoryId, 
      Date dateTimeFrom, Date dateTimeUntil) {
   if (name != null)
     // add name to criteria
   if (categoryId != null)
     // add category to criteria
   // ...
}

如果真的有很多不同的搜索操作,并且组合的数量非常高,您也可以尝试第二种选择.也许你可以通过简化和定制你的用例来限制你的Criteria“克隆”.

点赞