Почему Fetch должен быть последним предложением в запросе Linq Nhibernate

Question

Извлечение должно быть последним предложением в Linq, основанном на блоге Майка Хэдлоу :

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

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

Один случай, с которым я сталкиваюсь, - это использование AsPagination (MVCContrib) с Fetch. Потому что AsPagination пытается получить счетчик для запроса, который имеет Fetch, добавив .Count () в конец.

Итак, еще раз, почему стратегия выборки свойства должна быть последним предложением в операторе запроса Linq Nhibernate?

Answer 1

Я столкнулся с той же проблемой, прежде чем понял, что происходит. http://groups.google.com/group/nhibernate-development/browse_thread/thread/b44957841c9416ba

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

NHibernate всегда был сложным с точки зрения создания пейджинговых запросов, когда ваши сущности имеют связанные коллекции. Если вы используете Criteria или QueryOver, правильный способ сделать это состоит в том, чтобы пейджинговый запрос возвращал только идентификаторы сущностей с отдельной проекцией. Эти идентификаторы будут использоваться в условии where подзапроса, который будет содержать все объединения.

Пример вы можете увидеть здесь (ответ):

Критерии подкачки NHibernate с готовым режимом fetchmode. (используя свободный NH)

Я еще не пробовал эту технику в Nhibernate LINQ, но она может работать.