Hi, i'm implementing nHibernate in a medium-sized web project, basically based on web-services using the SOA architecture relying all the business logic behind web-services and using nHibernate for data access, the questions came when we've tried lazy initialization, it worked fine, but:

- Should we apply it to the entire project?
- Where should I pay attention where defining the lazy-loading behavior?

Thanx!
GermanK

in general, the Hibernate Team recommends using lazy loading for all associations.


in my opinion, i agree with the NH team, but certain instances seem to make more sense with lazy="false" in conjunction with <cache usage="read-only">. as an example, we have country objects each with a collection of states. in my mind, these are basically immutable and so here is the mapping:



this basically caches all country and state objects and improves performance when using Country and State objects. we have another instance with Survey and Questions collection. the survey rarely changes but almost always is used with the Survey.Questions collection so lazy="false" and <cache usage="read-write" /> applies for us here.

Excelent Devon!
And thanks for the quick response ;)

If you are serializing across web services, then how do you plan on lazy loading the objects on demand? When the objects are serailized to another application the connection is closed and you lost the ability to do any further lazy loading right?

We're implementing an Entity Layer that translates the persistance objects (nhibernates) to propiertary Entities, and those are the serializable class...

The translation is made by using an internal reference of the NH entity and the properties of my propietary entity access the NH entity's properties to expose them in the serialization and access from the service layer.

(Please excuse my bad english)

OK I understand. I have done something similiar and ended up with 4 classes for each object:

1 - NH mapped class
2 - Entity class service side
3 - Entity generated by web reference
4 - Entity class client side

To keep it under control we delete #3 and combine #2 and #4.

One problem that you may run into is that if you try to serialize a class that has lazy="true" and it was lazily initialized, XML serialization will fail. This is because Castle.DynamicProxy doesn't generate a no arg constructor for the proxy class it generates. XmlSerializer which is what ASP.NET web services uses for serialization requires this and as a result the serialization will fail.

I asked the developer of DynamicProxy if he could add a no arg constructor. However, as far as I can tell, he really doesn't give a damn and doesn't take the time to even bother responding. His claim seems to be that an iterceptor needs to be passed to the object. However, in the case of web services, you really only need the class to act as a data structure and don't need the proxy behavior anyways because the object has already been lazy initialized when it was serialized.

It's probably not a good idea to try to return these objects from a web service method anyway, but, it would be nice to be able to do it for simple cases.

It sounds like you aren't returning NHibernate returned objects from your web service methods, so, maybe you won't run into that problem.

That's not happening in my implementation, because from the beginning we did "wrap" the NH Entities into Domain Entities and mapped their properties to the NH Entities properties, so the serializations goes indirectly against the NH Entity, it serializes the Domain Entity.

Reduced sample:


That was the best approach we find to solve the Serialization problem, and also solved the IList serialization problem ;)

my two cents:

I didn't create different Entity Object Levels becuase I feel that they should be known throughout the Application Domain, = Domain Objects. The serialization issue is still an ongoing battle that I'm dealing with but I have one Entity Object project/namespace that's referenced from the DAO -> Business Rules -> Webservice -> Client (Dist. Winform App).

This makes the mapping for nHibernate completely relevant as the objects that are created are the domain objects. I was able to get around the Web Reference issue that MS creates by deleting the Domain objects that it creates and referencing my Domain Object namespace. All the "smarts" of the application truly lies in the Business Rules layer.