CSLA.Net V3.6 / NHibernate V2.10; как преодолеть потребность в жизненных свойствах - PullRequest
Новая
       16

CSLA.Net V3.6 / NHibernate V2.10; как преодолеть потребность в жизненных свойствах

4 голосов
/ 25 апреля 2009

В CSLA.net все доменные классы должны наследоваться от Businessbase, которая содержит не виртуальные свойства.

При использовании NHibernate нам нужно реализовать виртуальные свойства для отложенной загрузки.

Некоторые варианты совместного использования CSLA / NHibernate:

  • отключить отложенную загрузку в NHibernate и реализовать отложенную загрузку кода в классах домена (хотя это кажется менее гибким)
  • оставить отложенную загрузку в NHibernate, но использовать класс DTO для сопоставления с базой данных и передачи данных в классы домена CSLA

Какие еще варианты могут быть? Любые указатели в правильном направлении будут высоко оценены.

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

Ответы [ 4 ]

2 голосов
/ 25 апреля 2009

Вы можете создать интерфейсы для всех ваших отображаемых классов и указать, что NHibernate должен использовать этот интерфейс при создании прокси. Когда вы сделаете это, ваш конкретный класс домена не будет использоваться, пока экземпляр не будет инициализирован.

Например, вы можете сделать это в своем hbm.xml следующим образом: 

<class name="DomainModel.Entity, DomainModel" table="Entities" proxy="DomainModel.Api.IEntity, DomainModel">
    ...
</class>

Обратите внимание, однако, что это накладывает пару ограничений на то, как вы можете выполнять свои отображения. Например, вы не можете использовать стратегии доступа access="field.*". Прочтите этот пост о двух ленивых стратегиях загрузки, которые можно использовать.

1 голос
/ 27 мая 2009

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

Помните, что ваши бизнес-объекты не должны выглядеть как ваш слой данных. Объекты CSLA являются вашим бизнес-уровнем и должны быть гидратированы из вашего уровня доступа к данным ORM в ваших методах DataPortal_XYZ.

Возьмем, к примеру, простой пример структуры таблицы данных Users, Roles и UserRoles, где UserRoles - это таблица ссылок для связи пользователей с ролями. Это ваша схема данных, и она очень хорошо нормализует ваши данные.

Ваши бизнес-объекты НЕ должны выглядеть так, поскольку это не нормализует поведение. Когда вы думаете о бизнес-объекте User, у него должно быть свойство RoleList, представляющее собой список объектов Role. Не должно быть бизнес-объекта UserRole в существовании. Это может произойти, если вы пытаетесь перейти непосредственно из схемы базы данных и объектов CSLA.

1 голос
/ 25 мая 2009

Вы можете попробовать CSLA.Nhibernate из коробки или получить несколько подсказок от него.

CSLA.Nhibernate является частью CSLAContrib на codeplex. http://cslacontrib.codeplex.com/SourceControl/changeset/view/46985#302175

Не так много активности с тех пор. Но все, что реализовано, работает нормально. Путь SVN: https://cslacontrib.svn.codeplex.com/svn/ProjectTrackerNHibernate

0 голосов
/ 25 мая 2009

Вы можете указать 'lazy = false' в вашем отображении NHibernate на уровне класса. Это избавит от необходимости иметь виртуальные свойства, поскольку NHibernate не будет использовать динамические прокси. (это не влияет на лень коллекций). 

<class name="SomeClass" lazy="false">
   <id .... />

   <set name="SomeSet" ... >
   </set>
</class>

В приведенном выше примере класс отображается как «ленивый». Вам не понадобятся виртуальные свойства, но коллекция SomeSet может оставаться загруженной с отложенной загрузкой.

...