Nhibernate 3.2 Query против QueryOver

Question

Недавно мы обновили наш nHibernate до версии 3.2.Теперь мы добавили две новые опции для написания запросов - Query (LINQ) или QueryOver (iCriteria).

Из того, что я прочитал, QueryOver предназначен для nHibernate и более мощный для сложных запросов.С другой стороны, LINQ универсален, и если завтра я изменю свой ORM, мои запросы останутся без изменений.Еще одна важная причина для меня, чтобы использовать LINQ, это то, что в LINQ я нашел гораздо больше документации и примеров, чем в QueryOver.

На самом деле, я предпочитаю использовать LINQ, и я хочу быть уверен, чтокритическая причина, почему я не должен этого делать.

Заранее спасибо,

Answer 1

Вероятность того, что вы обменяете свой ORM, очень мала до нуля.

И у QueryOver, и у Query есть свои плюсы и минусы.

Но выгода NH в том, что вы можете легко щелкатьмежду любыми из его возможностей запроса.Там, где я работаю, мы используем смесь QueryOver (прежде всего), Query, HQL и иногда прямого SQL.

В то время как многие запросы LINQ от NH легко преобразуются в EF, LightSpeed ​​или по вашему выбору ORM,Существует целая куча специфичных для NH LINQ, таких как извлечение, которые встроены в провайдера LINQ, что затруднит выгрузку ORM в любой момент.

Иногда запросы QueryOver генерируют лучший SQL, чем Query,и наоборот, так что просто используйте то, что вы предпочитаете, и профилируйте запросы, когда они выполняются, чтобы обеспечить эффективность сгенерированного SQL.

Answer 2

На данный момент, к сожалению, оба имеют свои ограничения, и команда nHibernate проделает большую работу, чтобы соответствовать выразительности Linq2SQL, где большинство запросов просто работают.

Большую часть времени я использую Linq (Query), но у него возникают неожиданные проблемы с относительно простыми запросами, которые включают группировку и некоторые тонкие ошибки (например, печально известное «неверное приведение» в byte? https://nhibernate.jira.com/browse/NH-2812). Переключение на критерии api (QueryOver) обычно помогает.

На данный момент (3.2) невозможно дать прямую рекомендацию. Я бы придерживался Linq, временно переключаясь на критерии, когда вы сталкиваетесь с проблемами, и когда в будущих версиях будут устранены ошибки и ограничения, вы можете вернуться и попытаться переписать все в Linq, поскольку он должен служить основным языком запросов.