Компромиссы с использованием NHibernate 3.0 QueryOver или поставщика LINQ

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

Каковы основные компромиссы для использования каждого?

 Dan Abramov27 февр. 2011 г., 12:50
Я хотел бы видеть хорошее сравнение.

Ответы на вопрос(4)

Решение Вопроса

LINQ и QueryOver - это совершенно разные методы запросов, которые добавляются к тем, которые существовали в NHibernate 2 (Criteria, HQL, SQL).

QueryOver подразумевает строго типизированную версию Criteria и поддерживает в основном те же конструкции, которые специфичны для NHibernate.

LINQ - это «стандартный» метод запроса, который означает, что клиентский код может работать, IQueryable без явных ссылок на NHibernate. Он поддерживает другой набор конструкций; было бы трудно сказать, если есть больше или меньше, чем с QueryOver.

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

 Chris S20 авг. 2011 г., 19:43
В настоящее время поставщик LINQ имеет множество ошибок, например, SUM () не работает. QueryOver, хотя удаление refactor / magic-string хорошо, но немного медленнее, чем просто написание SQL на мой взгляд. В основном это связано с отсутствием документации за 1 страницу на nhforge
 Diego Mijelshon06 окт. 2010 г., 22:07
Например, LINQ пока не поддерживает левые соединения.
 Diego Mijelshon20 авг. 2011 г., 23:25
@Chris S: трекер ошибок всегда открыт:nhibernate.jira.com
 dotjosh06 окт. 2010 г., 21:52
Похоже, что выборка и кэширование поддерживаются провайдером LINQ, мне просто интересно, есть ли какие-либо подобные технические стены (сценарии присоединения и т. Д.), С которыми я мог бы столкнуться.
 Diego Mijelshon02 мар. 2011 г., 11:48
@StefanSteinegger: нет, это не так. Старый провайдер провайдера для NH 2.x был; новый основан на движке HQL.
 Stefan Steinegger02 мар. 2011 г., 12:02
@ Диего: вау, я этого не знал. Это серьезное изменение, которое позволит ему стать гораздо более мощным.
 Stefan Steinegger02 мар. 2011 г., 11:14
Разве linq для NH не основан на критериях / QueryOver? Нельзя, чтобы у Linq было больше возможностей. Это только может быть меньше.
 dotjosh06 окт. 2010 г., 22:33
Мне было интересно, если бы кто-нибудь мог внести свой вклад в этот список, я уверен, что он будет полезен для меня и других.
 Daniel Lang08 мар. 2011 г., 19:33
@ Стефан: Нет, на самом деле нет. Хотя новый поставщик намного лучше старого (который был действительно плохим), он все еще далек от завершения. На самом деле, до выпуска NH3 было некоторое обсуждение, должна ли быть названа поддержка бета-версии LINQ «бета», и для этого есть веские причины. Однако, похоже, что Фабио Мауло решил не называть это так, как это - неполная бета-версия.
 Darius Kucinskas01 мар. 2011 г., 12:10
На мой взгляд, синтаксис Linq для соединения очень уродлив и приводит к нечитаемому коду. По этой причине я использую Criteria API и QueryOver.

Я использовал как NH-Linq-провайдеров (старый NHContrib для Версии 2.1, так и новый для NH3.0), а также использовал QueryOver. Учитывая весь опыт, накопленный при разработке довольно сложных приложений, управляемых данными, я настоятельно рекомендую НЕ использовать существующего linq-провайдера с nHibernate, если вы планируете использовать только базовые CRUD-операции!

Текущая реализация (linq) иногда создает действительно нечитаемый, а также неэффективный SQL. Особенно объединение некоторых таблиц быстро становится кошмаром, если вы хотите оптимизировать производительность базы данных.

Несмотря на все эти недостатки, я никогда не сталкивался с неправильными запросами. Так что если вы не заботитесь о производительности и уже знакомы с LINQ, тогда переходите на NH-Linq. В противном случае QueryOver - ваш надежный и безопасный друг.

 Benjamin Schmid21 авг. 2015 г., 13:29
Пример из реального слова: одна задача сQuery заняло 10 с. Изменился наQueryOver без каких-либо других изменений: 1с
 PandaWood08 дек. 2016 г., 00:28
@BenjaminSchmid было бы хорошо, если бы вы могли показать этот запрос, даже с измененными именами и т. Д., Просто чтобы увидеть грубую сложность того, что может занять больше времени.
 Amit Joshi28 мар. 2018 г., 09:10
Ответ очень старый. Можете ли вы обновить свой ответ, чтобы охватить улучшения, если таковые имеются? Что ж, глядя на другой комментарий, я думаю, у него все еще много проблем.

Я начал использовать NH-Linq, потому что я уже покончил с LinqToSql и Entity Framework. Но для более сложных запросов я всегда заканчивал с QueryOver. Причины:

Бывает, что запрос с NH-Linq работает не так, как ожидалось. Я не могу вспомнить точно, но это не работает правильно с некоторыми сложными запросами. Кажется, это слишком молодо. И как говорилось в предыдущем ответе, это приводит к неэффективному SQL.Когда вы изучаете QueryOver, легко вызывать функции, выполнять проекции, подзапросы, мне кажется, легче, чем с NH-Linq.Хорошая вещь для NH-Linq - его можно расширить, как объяснил Фабио МаулоВот, Но подобное возможно с QueryOver, но не так красиво, как с NH-Linq :)

LINQ to NHibernate (начиная с версии 3.0) не поддерживает свойство .HasValue для типов Nullable. Нужно сравнивать с нулем в запросах.

Ваш ответ на вопрос