Request for alternative approach to Business object class properties in CSLA 3.6

jmcd posted on Monday, October 27, 2008

I recently posted on the forum about a problem I was having with Business Objects containing lists of child Business Objects (http://forums.lhotka.net/forums/thread/27194.aspx).  The problem seemed to be related to the fact that static fields weren’t being initialised early enough on deserialization (in part due to the management of class properties via the new FieldDataManager component and the way that .NET deserialises objects).  The reasons cited in a related thread (http://forums.lhotka.net/forums/thread/26807.aspx), seemed to suggest that it was due to my Child Business objects inheriting from my own base class (which in turn inherits from Csla.BusinessBase) instead of inheriting from Csla.BusinessBase directly.

(Note: The referred thread above is with regards to specializing from a base class – Csla.BusinessBase -> Customer -> GoodCustomer & BadCustomer whereas we inherit from a shared base class and then a generated class e.g. Csla.BusinessBase -> OrganisationBase -> CustomerBase (generated) -> Customer.)

In my organisation, it  is standard practice to inherit from our custom base class in order to avoid code duplication and share common concerns between all our business objects such as standardised exception processing (off-topic: we would also like to see CSLA use a ref for the Exception passed into DataPortal_OnDataPortalException for replacing/wrapping purposes).  The workaround suggested is to use a static dummy variable.  This works, however, in my opinion it doesn’t seem very elegant, requiring dummy variables throughout all our business objects.

Is there a possibility of a redesign at some point in the future which would negate the need for dummy variables in business objects not directly inheriting from Csla.BusinessBase?

JoeFallon1 replied on Monday, October 27, 2008

I agree that the static dummy variable solution is really ugly.

I have a large app and the move to 3.6 managed properties will be a real pain if I have to edit each BO in my hierarchy and slap this code in.

If there was a way to do it once in my own Base class then it would be trivial to implement. But Rocky has stated many times that each level of the chain needs it.

So if I have this hierarchy:

Csla -> MyBaseClass -> MyCodeGenClass -> MyDeveloperClass -> My Type

then I need to add the dummy variable code in 4 places!

One of the alternatives was to implement a static constructor but that had a serious performance drawback since it injects code *everywhere* in your classes to ensure it is initialized correctly. But even worse - Rocky mentioned it doesn't even work reliably in Csla so it is not even a possibility anymore.

It would be nice if a more elegant solution could be contrived.

Joe

 

ajj3085 replied on Monday, October 27, 2008

If you use static field initializes, you end up with a static constructor anyway.  So all that ugly code ends up in there anyway. 

So that's why using a static constructor doesn't help; you're just explicitly defining it instead of letting the compiler handler it, but the result is the same.

Rocky's trick works because you have an instance member trying to use the static member, so that ensures the static constructor fires.  Which is where all that ugly code likely ends up firing.

tmg4340 replied on Monday, October 27, 2008

I haven't followed the entirety of the conversations surrounding this issue, but I have seen quite a few of them.  And from what I've read, the answer is probably "no".

From what I have gathered, the issue is that .NET does not guarantee the initialization order of an inheritance chain.  That's what the static variable does - it forces an order of initialization so that the field manager collects everything in the proper order.  MS is not probably going to change that situation, since doing so would eliminate an optimization technique.  Given that, I know of no other way to take care of the situation - certainly nothing that would be considered more elegant than the current suggestion.  Apparently, neither does Rocky - I know that several solutions were tried before the dummy-variable solution was settled on.

Having not done an extensive study of the 3.5 codebase, I can't say how much order is important.  There are surely ways to re-factor the code to eliminate the dependency on ordering, but moving to a key-based solution would almost certainly introduce a performance hit.  Given how much the field manager is accessed, that could very well be significant.

HTH

- Scott

Fintanv replied on Tuesday, October 28, 2008

The problem comes when you try to access properties defined in the base class, from an inherited child.  There is no guarantee that the static parent properties have been initialized, leading to null reference errors.

If the MS developers of the compiler had the same foresight and regard for developers as our own Rocky, they would have made the 'optimization' you mention optional via a switch, and ensured the whole thing was backwards compatible .