Биндить данные для комбобоксов нужно так, как это делают всегда. Когда набор сущностей прибиндился, то декларативно заюзать аттрибут парентовой (референсной) сущности можно так, как я показал в прошлом посте. Экспериментируйте.
P.S. Толко Вы должны понимать, что при бинде каждой сущности в комбобоксе будет происходить Lazy запрос на сервер.
P.S2. В плане отпимизации исполняемого SQL кода за такой подход обычно отрезают нижнюю челюсть. Поэтому, планируйте подобные выборки средствами серверных представлений, функций и/или хранимых процедур.
P.S3. ORM универсальный инструмент, а не оптимальный. Нужно это помнить.

КурдльНо Вы в курсе, что хибер не работает в полной мере с ораклевыми ХП? :(
Смотря что понимать под "полной мерой" ;)

КурдльЭто надо понимать так: "позволяет исполнять любые валидные хранимые процедуры и функции оракла, корректно передавая значения входных параметров и получая правильные значения выходных параметров и результатов функций".
Как-то так...
И в чем именно выражается отказ оракулевых процедур и функций от правильной работы?
P.S. Как-то Вы пальцем в небо... Конкретнее нужно, конкретнее. Агрументы нынче в цене.

КурдльС функциями Nhibernate работает лишь через "select FUNCTION_1(:PARAM_1) as :RESULT_1 from dual"
Кто Вам такие глупости рассказал?


КурдльКроме того, и в функциях и в процедурах Nhibernate не понимает OUT параметров, только если это не REF CURSOR.


тут

Вот тут показана педаль под вызов процы вне пакета.

КурдльИз приведенных Вами примеров с функцией один использует "select scalartest.getnumberofrows as TotalRows from dual" (как я и говорил постом ранее)
Это просто пример. Никто не запрещает юзать недуальность.
Курдльа другой - требует получения IDbCommand (что перечеркивает все достоинства Nhibernate).
Почему перечеркивает?
Курдльесли Вы подыщете вариант вызова ХП и функций оракла с OUT-параметрами без использования IDBConnection.
Мне обычно плевать на признания :) Это работает и славно. Остальное втопку.

КурдльОдним из крупных "за" Nhibernate декларировалась "независимость от СУБД".
А оказывается, что это не так.
Глупости. Всё крутится на основе провайдеров к БД. Если провайдер может работать с какими-то специфическими фичами СУБД, значит и хибер сможет. Я Вам привел пример кастома провайдера, но Вы смотрите не в корень, а на поверхность (увидели дуал и начали вопить, что я левый пример дал).
КурдльПодход, при котором приходится танцевать с бубном, перечеркивает это достоинство.
IDBConnection - это танец с бубном? Тогда, батенька, Вам не в программисты, а в сельское хозяйство.
P.S. Для каких-то ветвей решения можно заюзать и IDBConnection, ничего предсудительного тут нет.
P.S2. Тоже самое и в других ORM, например в Linq to SQL. Возьмем классическую задачу: удаление сущности по ID (без лишнего перезапроса).



Как видите, и тут DbCommand приходит на помощь.

P.S3. Прекращайте ныть и начинайте работать :)

Курдль, современные технологии тут как-бы непричём. Для себя просто попытайтесь ответить: нужно ли оно Вам. Если нужно - забейте на религиозные мотивы и прочие порывы души: просто исполуйте ORM и всё. Если сомневаетесь - пишите по-старинке и не пукайте :)
P.S. От себя отвечу, ORM сильно упрощает жизнь. Особенно в поддержке кода.

Подводные камни есть в любом деле, даже в уборке картофеля с картофельных полей.
Во-вторых, только на реальных проектах Вы сможете вполтную прочувствовать хибер. Иначе, это как в магазине: я пришел покупать конфету, до этого ее не пробовав. Я много читал про нее, про нее много говорили. Но, пока реально не попробуешь - не скажешь, какого вкуса она. Вы поковырялись, слегонца прочувствовали хиб. Этого достаточно. Теперь скажите, нужно ли оно Вам? Если да - вперёд, если нет - не ипите моск форумчанам :)