Где я должен использовать Hibernate Criteria в архитектуре MVC?

Question

Я работаю над проектом CRM, который использует Spring MVC и Hibernate, и я не знаю, как лучше всего использовать критерии гибернации.Я хочу использовать критерии гибернации, потому что у нас есть возможность поиска на нашем уровне представления, и пользователи могут искать по множеству различных параметров по-разному.Иногда нам просто нужны идентификаторы, иногда нам нужно подмножество свойств, иногда нам нужно объединить несколько таблиц и т. Д. Итак, построение структурированных критериев, таких как критерии гибернации, вместо передачи списка параметров, заказов, необходимых параметров и ограничений поиска из представленияслой к слою данных, может очистить код.Тем не менее, я знаю, что неправильно использовать hibernate на уровне представления, так как это противоречит архитектуре MVC.И я действительно не думаю, что дублирование критериев гибернации является правильным подходом.Я мог бы подумать о 3 подходах:

1. Создание дюжины методов на бизнес-уровне, по одному для каждого типа поисковых запросов, и вызов каждой из этих функций из уровня представления в зависимости от ситуации.Каждый из этих методов, по сути, ничего не делает, кроме передачи параметров в соответствующий метод DAO, который создает запрос SQL (или объект критерия) и извлекает данные из базы данных.При таком подходе я получу сотни методов, которые ничего не делают, кроме передачи параметров в DAO.

2. Создание класса, аналогичного классу критериев Hibernate в презентации (или бизнес-уровне)).Затем инициируем этот объект с параметрами поиска на уровне представления и передаем его в DAO.Затем DAO создает объект критериев гибернации на основе этого объекта.Этот подход предполагает дублирование класса критериев hibernate.

3. Инициирование класса Cibereria Hibernate на уровне представления и передача его в DAO для получения результата поиска.

Можете ли вы дать мне знать, какой из них лучше?

Спасибо

Answer 1

Другой вариант - создать слой, специфичный для запроса.Эта концепция исходит от CQRS.Я не использую NHibernate, но я использую ADO.NET для непосредственного выполнения моих запросов, поскольку я согласен с идеей, что модель домена не следует запрашивать.Нет ничего плохого в загрузке полной совокупности здесь и там, но определенно не для специальных запросов.

Итак, гипотетически, вы можете получить что-то вроде ContactQuery с такими методами, как

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

Таким образом, ваши запросы абстрагируются.Надеемся, что проекции NHibernate возвращают DataRow / DataTable:)

Answer 2

Я думаю, что лучший выбор зависит от ваших запросов.

Если возможно, я бы порекомендовал вам перейти на первый вариант.Я часто внедряю методы поиска DAO, которые принимают много обнуляемых параметров.Сам метод DAO строит критерии добавления объекта критериев, если соответствующие параметры метода не установлены в NULL.

Это простой пример:

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
   // ...
}

Если действительно много разныхПоисковые операции и количество комбинаций очень велики, вы также можете попробовать второй вариант.Возможно, вы можете ограничить свой критерий «клонирования», упростив и адаптировав его для своих вариантов использования.

Answer 3

Я бы начал создавать и передавать объекты Criteria на уровень DAO.Причина двоякая:

1. для предотвращения естественного взрыва методов поиска в DAO
2. , чтобы избежать дублирования кода (что присуще второму варианту).1008 * Таким образом, вы можете рассматривать объекты критериев как часть слоя вертикальной области.

   PS Я не знаю вашей ситуации, но несколько лучшим вариантом может быть использование JPA 2 Criteria в качестве стандартной "альтернативы"Критерии Hibernate только для того, чтобы избежать зависимости от особенностей Hibernate без острой необходимости.