Интересует, жизнеспособно ли решение? Может, кто применял нечто подобное...

В модели предметной области создаем 2 класса, отображаемых на одну таблицу (для наглядности - Document и DocumentLight).

Один из них (Document) - в полной мере описывает какую-либо сущность предметной области. У этого класса есть наследники (SubDocument1, ... , SubDocumentN).

Второй класс (DocumentLight) - облегченный и используется только для чтения. В нем замэплены лишь несколько самых необходимых свойств. Наследников у него гарантированно нет, и применяется он для быстрого запроса списков с достаточным минимумом информации (основное поле - это идентификатор id). Далее уже для конкретного id, выбранного в списке DocumentLight, будет извлекаться объект класса Document (а точнее одного из его подклассов, NHibernate определит автоматически).

При этом при построении списка из DocumentLight мы осуществляем запрос только к одной таблице - обходимся без join'ов со всеми таблицами подклассов...

Как-то так....

SolYUtor,

Спасибо большое за наводку! Пойду читать доки...

ps. сам никак не мог найти свойства, отключающее подгрузку подклассов...

Курдль
А критериальными проекциями не решается?

Судя по всему, решается... В предыдущем посте дали направление, в каком копать, и вот, похоже, нашел то что нужно - с проекциями и трансформерами.

МСУbarserИнтересует, жизнеспособно ли решение?
Не жизнеспособно. Во-первых, это реально не нужно (детское ребячество отбросим), во-вторых, при таком подходе нельзя будет сгенерить БД по маппингам.

Одна таблица - один класс. Все остальные потуги вколбасить в маппинги енумы, проецирующиеся с реальных таблиц и иже - самозаёп. Да и только.

Понял, спасибо за ответ.

Одна таблица - один класс...
Именно этого принципа стараюсь придерживаться.
Однако, к примеру, когда у документа есть штук 5 наследников, вызов getEntity(typeof(Document)) генерирует sql-запрос c пятью join'ами... И с ростом числа наследников число join'ов соответственно возрастает... Так-то пока все работает как часы, но не хотелось бы столкнуться с проблемами в будущем. Вот нашел время, чтобы убрать эти join'ы там, где они 100% не нужны. А наиболее подходящей методики для этого не знал/не нашел (еще думал, как вариант, использовать createSQLQuery() )

Немного не по теме - генерация БД по маппингам - наверное, удобная фича и в следующем проекте я бы ее с удовольствием опробовал.
Но в текущем - у меня нет полномочий определять _все_ архитектурные решения, а также недостаточно опыта для этого...
Вначале были приняты правила, по которым мы создаем таблицы вручную и после этого мэппим с классами. Так что сейчас этот плюс неактуален.
Кстати, неудобство некоторых правил, принятых вначале, сейчас становится очевидно - например, тот факт, что в качестве id используем number из оракловых сиквенсов не дает тестировать слой DAO на базе sqlite без внесений изменений во все части мэппинга... а могло бы быть гораздо удобнее... ну и т.п....

КурдльbarserНемного не по теме - генерация БД по маппингам - наверное, удобная фича и в следующем проекте я бы ее с удовольствием опробовал.

мы создаем таблицы вручную

Не рекомендую делать ни первое, ни второе. Воспользуйтесь специализированными CASE-инструментами для создания логической, концептуальной, а из нее - физической модели БД. Потом получите скрипт для любой СУБД.
Ни одна из ОРМ или сред разработки DDD и близко не подошла к тому качественному уровню, на котором сейчас находятся старые-добрые средства создания БД.

barser
Кстати, неудобство некоторых правил, принятых вначале, сейчас становится очевидно - например, тот факт, что в качестве id используем number из оракловых сиквенсов...

А тут подробнее - что за проблемы и какие альтернативы?

Ок, спасибо, посмотрю...
Ну, вообще-то изначально мы использовали Enterprise Architect для создания модели и соответствующих таблиц. Он, помимо прочего, позволяет генерить и C# код, и скрипты генерации таблиц в Oracle (кстати, еще и документацию удобно компонует). Вот правда сейчас пошли в обратную сторону - в EA теперь только время от времени импортируется текущее состояние проекта из Visual Studio... Да и вообще это мощное средство используем не так широко, как стоило бы :)

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

Курдльbarser,

Меня интересовало, какие проблемы с сиквенсами.
А теперь заинтересовало, как это "молодец - хибер" поддерживает ХП оракла, напр. с OUT и IN параметрами одновременно (сам над этим убивался, да так и не победил).

Я тоже немало времени на решение убил... В итоге у меня в тестах есть кусок кода вызова хранимки, возвращающий рефкурсор... Храню как память :) А вообще - гораздо проще спускаться на уровень ADO.NET для их вызова...
Там важна позиция параметров - out должен идти первым. (на Summer of Nhibernate есть видео на эту тему)

Ща запостю:




Насчет сиквенсов:
вот это
приходится менять на что-нить типа ....GeneratedBy.Native(); так как sqlite не понимает, о чем речь

МСУbarser, ничё не понимаю, у Вас флюент и hbm маппинги в одном флаконе курятся?

У нас всё на флюенте.
Просто имхо namedQuery удобнее в xml держать, но мы их практически не используем (пока что)