Hi all, I've looked at the docs and browsed through the forum (although I haven't real ALL the topics) but I can't seem to find an answer to my question so here goes:

In my class Customer I have a IList property called "Offers". I leave the corresponding IList member variable uninitialized (i.e. Nothing), counting on NHibernate to supply me with a reference to one of its collection instances.

This works fine for existing Customers, even those who don't have any offers yet (I just get an empty collection). However, when I create a new Customer object and I call ISession.SaveOrUpdate() on it the value of the Offers property (i.e. Nothing) is not changed so that it references an empty NHibernate collection.

From the code in Impl\WrapVisitor.cs (ProcessArrayOrNewCollection method) I can see this behaviour is by design. Does this mean I am supposed to initialize the IList member variables in my Business Logic classes to an empty collection myself for the ProcessArrayOrNewCollection() method to work its magic ?

Thanks for any light anyone can shed on this for me.

Sven

(I'm still using NH 0.8.4 for now)

Yes, you have to initialize them... (using ArrayList for ex.)

Yes, you should create the initial collection yourself. The usual way is to either do it in a constructor, or in the property getter.

Awesome guys. This is what I thought but thanks for taking the time to confirm.

Out of curiousity, is this mentioned somewhere in the docs? Did I miss it ?

Thanks

the pattern i usually use is:



And you should omit the setter. You should rather tell NHibernate what accessor to use as it can modify your private fields too. Look at the documentation of the mapping.

RGabo

I'm curious as to why I should omit the setter ? I would like to allow "users" to replace the collection with a new one, transient or not. From reading around I had gathered this was possible as long as the new collection conforms to the right interface (i.e. Ilist, IDictionary or ISet).

This is more of a .NET design guideline, than an NHibernate practice. You wouldn't want that someone who uses your class library could set the underlying field to anything. It could leave the object in an invalid state, for instance:

Parent.Children = null;

// ...

later
Parent.Children.Add("Jimmy");

will throw a null reference exception.

I think this is just a matter of personal preference, but if you read about .NET design guidelines or have seen Brad Abrams speak about it (available as webcast too), he might give you some good points on things like this.