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

我正在使用Spring MVC和Hibernate的CRM项目，我不知道什么是最好的地方使用休眠条件。我想使用hibernate标准，因为我们在表示层上具有搜索功能，用户可以用不同的方式基于大量各种参数进行搜索。有时候我们只需要ID，有时候我们需要属性的一个子集，有时候我们需要加入多个表等等。所以，建立一个像Hibernate的标准这样的结构化标准，而不是传递参数列表，命令，要求参数和搜索限制层到数据层，可以清理代码。但是，我知道在表示层中使用hibernate是不正确的，因为它违背了MVC体系结构。我真的不认为重复hibernate的标准是正确的方法。我能想到的3种方法：我应该在MVC架构中使用Hibernate Criteria？

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

您能否让我知道哪一个是最好的方法？

谢谢

来源

2011-10-04 Babak

我认为最好的选择取决于您的查询要求。

如果可能，我会建议你去第一个选择。我经常发现自己实现了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“克隆”。

来源

2011-10-04 02:10:39

感谢Matthias的回答。第一种方法是我去年开始做的事情，结果在DAO中有大量复杂的方法，因为除了大量的搜索参数之外，我们还需要各种表连接和投影（限制哪些列需要加载）。所以，我在一段时间后选择了第二种方法，并构建了自己的Criteria类，并开始扩展它，并重复了大部分hibernate的标准功能。所以，我想知道什么是常用的方法。也许在表示层使用Hibernate的Criteria并不是一个坏主意。 – Babak

另一种选择是创建查询特定的图层。这个概念来自CQRS。我不使用NHibernate，但我确实使用ADO.NET来直接执行我的查询，因为我订阅了不应查询域模型的想法。加载一个完整的聚合在这里，但没有错，但肯定是而不是临时查询。

所以，假设，你可以有像ContactQuery与方法，如：

public string Name(Guid contactId)
public DataRow Details(Guid contactId)
public DataTable CustomerContacts(Guid customerId)

这样你的查询被抽象。希望NHibernate预测返回DataRow/DataTable :)

来源

2011-10-04 04:29:17

谢谢。这是另一个不错的选择。 – Babak

我会去创建并向前传递Criteria对象到DAO层。原因是双重的：

防止finder方法自然爆炸DAO中
以避免重复代码（这是在第二个选项固有）。

因此，您可以将标准对象视为垂直域图层的一部分。

P.S.我不知道你的情况，但稍微好一点的选择可能是使用JPA 2 Criteria作为Hibernate Criteria的标准“替代”，只是为了避免依赖Hibernate特有的功能而没有强大的必要性。

来源

2011-11-23 16:31:05 Dmitri

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

回答

相关问题