Geek Answers Handbook

CSLA.Net V3.6 / NHibernate V2.10; how to overcome the need for vitality

With CSLA.net, all domain classes must inherit from Businessbase, which contains non-virtual properties.

When using NHibernate, we need to implement virtual properties for lazy loading.

Some uses of CSLA / NHibernate together are as follows:

  • disable lazy loading in NHibernate and implement lazy loading code in domain classes (although this seems less flexible)
  • leave the lazy load in NHibernate, but use the DTO class to map to the database, and then transfer the data to the CSLA domain classes.

What other options could there be? Any pointers in the right direction would be highly appreciated.

I believe the above question is really applicable to using NHibernate with any structure.

+4
source share
4 answers

You can create interfaces for all of your associated classes and specify that NHibernate should use this interface when creating proxies. When you do this, your particular domain class will not be used until the instance is initialized.

For example, you can do this in your hbm.xml as follows:

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

Please note, however, that this creates several limitations as to how you can perform your mappings. For example, you cannot use access strategies access="field.*" . Check out this post for two lazy loading strategies you can use.

+2
source

You can try CSLA.Nhibernate out of the box or you can get some tips from the same.

CSLA.Nhibernate is part of CSLAContrib on codeplex. http://cslacontrib.codeplex.com/SourceControl/changeset/view/46985#302175

Not a lot of activity since. But everything that was implemented works fine. SVN path: https://cslacontrib.svn.codeplex.com/svn/ProjectTrackerNHibernate

+1
source

I believe the right rule is to create a DTO level between your business layer and data access. I have done this in many projects, and I have had great success.

Please keep in mind that your business objects should not look / feel like your data layer. CSLA objects are your business layer and should be humidified from the data access ORM level in your DataPortal_XYZ methods.

Take, for example, a simple example of the structure of the Users, Roles, and UserRoles data tables, where UserRoles is a link table to associate users with roles. This is your data scheme, and it is very good at normalizing your data.

Your business objects should NOT look like this does not normalize bahavior. When you think of a user’s business object, it should have a RoleList property, which is a list of Role objects. There really shouldn't be a UserRole business object. This will happen if you try to jump directly from the database schema and CSLA objects.

+1
source

You can specify "lazy = false" in your NHibernate class-level mapping. This eliminates the need for virtual properties, since NHibernate will not use dynamic proxies then. (this does not affect laziness of collections).

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

In the above example, the class appears as "lazy." You do not need virtual properties, but the SomeSet collection may remain lazy.

0
source

More articles:


All Articles