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

При использовании CSLA.net все классы домена должны быть унаследованы от Businessbase, который содержит невиртуальные свойства.

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

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

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

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

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


.net nhibernate csla
person Community    schedule 25.04.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

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

Например, вы можете сделать это в своем hbm.xml вот так:

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

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

person mookid8000    schedule 25.04.2009

arrow_upward
1
arrow_downward

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

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

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

person Sachin Chavan    schedule 25.05.2009

arrow_upward
1
arrow_downward

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

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

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

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

person Jamie Wright    schedule 27.05.2009

arrow_upward
0
arrow_downward

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

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

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

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

person Frederik Gheysels    schedule 25.05.2009