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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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