I'm thinking of using nHibernate on a new project and having read some of the documentation I realise that nHibernate supports automatic properties and I also understand how nHibernate used the private variable ('_XXX') with previous versions of .Net to set the property value via reflection.

Some of the domain model entities will not expose a public setter automatic properties they will use method such as 'Add' or 'AddRange' - these will generally be entity properties that represent collections. The reason for this is because I wish to do some basic validation and set a parent-child relationship.

Is there anyway using nHibernate to call an explicit method like 'Add'\'AddRange' to add a property to collection that is exposed by a getter method?


Cheers

Ollie

If its a collection you can implement a custom collectiontype

It's probably best to give a simple example, I wwant to know if it is possible to persist\hydrate the property 'Chidlren' on the 'Foo' class using the following methods?

Jeg this would work. nHibernate has no problem with accesing a private setter when hydrating the objekt. So know problem there your property will be published with its values. And when persisting the getter will be used.

Thanks for the response, I know that nHibernate can access the private variable to 'set' the property, but this would miss some of the business logic I wish to apply to each member of the collection when it is added.

Cheers

Ollie

But when i assume your database is consistent, so that items can be added directly to the property and when using the object manually you use the methods?

A problem is that in your example the collection can be added directly so it should prbaply be returned read-only

I can see from another fourm post that one can create bi-directional mappings - http://forum.hibernate.org/viewtopic.php?t=984636&highlight=parent+reference

This does make me wonder why bi-directional mapping are percieved as a bad idea?


Cheers

Ollie

Im not quite sure i follow this in the context of your original question. But i would argue bidirectional mappings removes flexibility to have properties in the relation itself

I think the idea is that NHibernate assumes that when it's hydrating an object, that it's just bring back into memory what was once in memory some time ago and then persisted. So, if you have the following lifecycle..


1.) New object is created.
2.) Entity is added to collection via the Add method, which includes validation. Let's say that all checks in the Add method are OK, thus the Bar object is successfully added to the Children collection.
3.) Save() is called, persisting the entity to the DB.
4.) You close your program and make yourself a sandwich.
5.) You open your program, calling Load<Foo>(id)


Since the DB should only have entities that already did pass the validation in Add, it's redundant to check them again in AddRange. If the Bar entity you passed duing your pre-lunch session didn't pass the validation in Add, it would never have been persisted.

As jta explained, by not making your set publicly available, and instead forcing the user of the class to use your methods with the validation in them, you should be able to safely say that every entity in the collection passed the validation.

Now, there may be exceptions, two I can think of are...

1.) Your DB is being shared with another program that doesn't use your validation.
2.) You are creating a new version of your program that has tighter validation than a previous version, and entities in the DB might have been valid in a previous version, but no longer valid in the new version.

In either case, you may want to go with more of a passive validation scheme (using an IsValid() method on foo, for example). In the second case, you might also want to think of alter scripts for your database to bring entities that would become invalid into a valid state.

Hope that helps.