NHibernate w/ Managed Properties w/o losing easier Silverlight possibilities?

NHibernate w/ Managed Properties w/o losing easier Silverlight possibilities?

Old forum URL: forums.lhotka.net/forums/t/6030.aspx


skagen00 posted on Friday, December 19, 2008

This is kind of an obscure question and perhaps it's not entirely correct if I am making incorrect assumptions.

David Dilworth stated that NHibernate effectively loads his CSLA object with NHibernate in a very generic nature, where NHibernate ends up populating private fields in the business object.

Managed Properties *can* use a private backing field, of course, and I suspect if NHibernate is accustomed to writing to a private backing field that this is what would need to be done.

I haven't looked at this yet, but I assume the FieldManager doesn't store the data doubly - that is, both in a private backing field and in the FieldManager collection.

If private backing fields are used, I gathered from the demonstration that Sergey re-did (thanks, Sergey), that one would have to write your own serialization routine in regards to Silverlight.

If I miraculously quoted everything accurately, I was wondering, David, if you've thought about this and if loading into the FieldManager without using private backing fields is a possibility with NHibernate. I'm debating whether or not to look into this tool as you have seemed to be very pleased with this - plus I'm a little wary of touching the EF and LINQ to SQL avenues with all the flux lately.

One thing I liked about what you had said about NHibernate is the omission of that extra copy into an intermediate object (this going back into a very old thread).

I'm looking at a future project that may end up using CSLA, and while Silverlight isn't the immediate UI most likely, I want to be faithful to an avenue that would support it.

RockfordLhotka replied on Saturday, December 20, 2008

If you use private backing fields, and you want to use Silverlight (and in the future things like Azure or other medium/low trust environments) then you'll need to do extra work in your business class.

You won't need to write your own serializer or anything like that. The MobileFormatter we created for Silverlight does include this scenario as a supported thing - but you must participate.

Specifically, you must override OnGetState() and OnSetState() and get/set your private field values into a property bag - a dictionary provided to you by the serializer.

If you did any VB5 or VB6 code, you might remember the property bag pattern that was used, and this is essentially the same model It is a well understood pattern for externalizing state (the Memento design pattern for the GoF fans) without using reflection or anything beyond standard language constructs.

But it does mean you need a line of code per field in each of these two methods. Forget one or both and your app will "run", just not correctly. This leads to hard-to-debug bugs - though I suppose thorough unit tests for serialization may help catch this. Though if you add a property to your object and forget to add the get/set lines, you'll probably also forget to update the unit test :)

rsbaker0 replied on Saturday, December 20, 2008

skagen00:

... I haven't looked at this yet, but I assume the FieldManager doesn't store the data doubly - that is, both in a private backing field and in the FieldManager collection.

I had asked a similar question a week or so ago but didn't get a reply.

However, I believe this is true as long as you exclusively use private backing fields. As soon as you load or reference a single property in the same object where CSLA manages the storage, I think the FieldManager will allocate an array based on the total number of managed properties. I'm not sure about this though, which is why I asked...

Copyright (c) Marimer LLC