У меня есть запрос, который по соображениям производительности мне нужно создать фактическую команду с использованием необработанного ADO.NET (он включает параметры, возвращающие табличное значение). С LINQ to SQL или EF я мог просто передать DbDataReader, который был возвращен DbCommand.ExecuteReader(), методу DataContext.Translate<T>(DbDataReader) или ObjectContext.Translate<T>(DbDataReader), и он преобразовал бы набор результатов в объекты , возвращая IEnumerable<T>.

Есть ли в NHibernate эквивалентный API, которому я могу передать DbDataReader / IDataReader или даже DbCommand / IDbCommand и получить обратно объекты NHibernate?

Или, возможно, есть способ перехватить построение команды, созданной ISession.CreateQuery(string), чтобы я мог изменить базовый DbCommand, чтобы он работал так, как мне нужно?

0
Allon Guralnek 7 Апр 2013 в 13:36
Есть ли причина, по которой вы не можете использовать CreateSQLQuery?
 – 
mickfold
7 Апр 2013 в 19:44
@penfold: Да, потому что, как я уже упоминал, мне нужно использовать возвращающие табличное значение параметры.
 – 
Allon Guralnek
7 Апр 2013 в 21:19

1 ответ

Лучший ответ

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

NHibernate не предоставляет преобразование DataReader -> entity в каких-либо общедоступных методах.

1
Diego Mijelshon 7 Апр 2013 в 21:58
Похоже, это хорошее место для начала. IUserType.NullSafeSet() имеет параметр типа IDbCommand, который мне нужен для добавления параметра табличного значения.
 – 
Allon Guralnek
7 Апр 2013 в 23:55
Это действительно был самый простой способ сделать это, спасибо! Я дошел до того, что смог сделать следующее: session.CreateSQLQuery("SELECT * FROM Customers WHERE Id IN (SELECT Value FROM :tableType)"). Но для этого требуется вызов IQuery.AddEntity() и тому подобное. Я попытался переместиться на один уровень абстракции вверх, используя HQL со следующим: session.CreateQuery("FROM Customers WHERE Id IN (SELECT Value FROM :tableType)"), но это выдает Antlr.Runtime.NoViableAltException. Я хочу перейти к тому моменту, когда я смогу использовать это из LINQ, но разве HQL не является следующим логическим шагом? Может мне нужно пропустить HQL?
 – 
Allon Guralnek
8 Апр 2013 в 17:33
Я не думаю, что вы сможете подняться выше SQL без более глубокого взлома. Просто сохраните SQL.
 – 
Diego Mijelshon
8 Апр 2013 в 17:56