Лучшие практики для запросов с помощью NHibernate

Question

Я вернулся к использованию NHibernate после использования других технологий ( CSLA и Subsonic ) в течение нескольких лет, и я нахожу запросы немного разочаровывающими, особенно по сравнению с дозвуковым. Мне было интересно, какие другие подходы люди используют?

Язык запросов Hibernate мне не подходит, кажется, что это слишком похоже на написание SQL, что, на мой взгляд, является одной из причин использовать инструменты ORM, поэтому мне не нужно, более того, все это в XML, что означает, что это плохо для рефакторинга, и ошибки будут обнаружены только во время выполнения?

Критерии запросов, не кажется достаточно текучими.

Я прочитал , что Ayende Генератор запросов NHibernate , является полезным инструментом, это то, что люди используют? Что еще там?

РЕДАКТИРОВАТЬ: стоит прочитать http://www.ayende.com/Blog/archive/2007/03/17/Implementing-Linq-for-NHibernate-A-How-To-Guide--Part.aspx

Answer 1

Что-то с LINQ для NHibernate все еще находится в бета-версии; Я с нетерпением жду NHibernate 2.1, где, по их словам, он наконец-то сделает разрез.

Я сделал презентацию на LINQ для NHibernate около месяца назад, вы можете найти ее полезной. Я написал об этом здесь, включая слайды и код:

LINQ для NHibernate: отображение O / R в слайдах и коде Visual Studio 2008

Answer 2

Чтобы избавиться от XML, попробуйте Свободный NHibernate

Linq2NH еще не полностью испечен. Основная команда работает над реализацией, отличной от той, что в NH Contrib. Это работает хорошо для простых запросов, хотя. Используйте экономно, если вообще для достижения наилучших результатов.

Что касается того, как делать запросы (hql против критериев против Linq2NH), предоставьте методы выявления намерений (GetProductsForOrder(Order order), GetCustomersThatPurchasedProduct(Product product) и т. Д.) В интерфейсе своего хранилища и реализуйте их наилучшим образом. Простые запросы могут быть проще с hql, при этом используя шаблон спецификации, вы можете найти API Criteria более подходящим. Эти вещи просто остаются инкапсулированными в вашем хранилище, и если ваши тесты пройдут, это не имеет большого значения, как вы реализуете.

Я обнаружил, что API Criteria громоздок и ограничен, но гибок. HQL - это скорее мой стиль (и он лучше, чем SQL - он основан на объектах, а не на схемах) и, кажется, лучше работает для простых методов GetX ..

Answer 3

Альтернативой LINQ-to-NHibernate и NHQG Айенде является создание выражений / ограничений NHibernate из выражений C # 3. Таким образом, вы получите более строго типизированный Criteria API.

См:

• http://bugsquash.blogspot.com/2008/03/strongly-typed-nhibernate-criteria-with.html
• http://www.kowitz.net/archive/2008/08/17/what-would-nhibernate-icriteria-look-like-in-.net-3.5.aspx
• http://nhibernate.info/blog/2009/01/07/typesafe-icriteria-using-lambda-expressions.html

Answer 4

Я использую Linq для NHibernate по умолчанию. Когда я сталкиваюсь с ошибками или ограничениями, я переключаюсь на HQL.

Это чистый подход, если вы храните все свои запросы вместе в классе доступа к данным, таком как Repository.

public class CustomerRepostitory()
{ 
  //LINQ for NHibernate     
  public Customer[] FindCustomerByEmail(string email)
  {
     return (from c in _session.Linq<Customer>() where c.Email == email).FirstOrDefault();
  }

  //HQL
  public Customer[] FindBestBuyers()
  {
    var q = _session.CreateQuery("...insert complex HQL here...");
    return q.List<Customer>();
  }
}

Вы спрашивали о рефакторинге. Очевидно, что над LINQ позаботится IDE, поэтому для любого оставшегося HQL довольно легко отсканировать эти классы репозитория и вручную изменить HQL.

Хорошей практикой является использование HQL в XML-файлах. Может быть, посмотрите, сможет ли плагин ReSharper NHIbernate *1009* обрабатывать рефакторинг запросов к настоящему моменту?

A большой улучшение при написании или рефакторинге запросов (HQL или LINQ) состоит в том, чтобы поместить методы поиска в модульный тест . Таким образом, вы можете быстро настроить HQL / LINQ, пока не получите зеленую полосу. Цикл компиляции / тестирования / обратной связи очень быстрый, особенно если вы используете базу данных в памяти для тестирования.

Кроме того, если вы забудете отредактировать HQL после рефакторинга, модульные тесты должны очень быстро сообщить вам о сломанном HQL.

Answer 5

утилизируйте nHibernate и вернитесь в Subsonic, если можете. На мой взгляд, Subsonic - гораздо более беглый и тестируемый ORM / DAL. Я абсолютно ненавижу HQL, в чем смысл слабо типизированного запроса в ORM? И зачем мне использовать Linq / nH / SQL, когда я могу просто использовать Linq to SQL и вырезать слой?

nHibernate был хорошим ORM, когда Subsonic не было рядом, но сейчас работать с ним просто ужасно. Мне легко в 2 раза дольше работать с nHibernate против Subsonic. Тестирование является трудной задачей, поскольку nHibernate является средой выполнения, поэтому теперь мне нужно нанять несколько инженеров QA, чтобы «щелкнуть» по сайту, а не получить ошибку во время компиляции.