Why isn't PropertyInfoManager contained within BusinessBase similar to how FieldManager is?

Why isn't PropertyInfoManager contained within BusinessBase similar to how FieldManager is?

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


pbusch posted on Monday, February 28, 2011

I know that FieldManager is exposed as a protected property within BusinessBase.  Why isn't PropertyInfoManager setup the same way?  From what I can gather, PropertyInfoManger maintains a dictionary of Types and a list of each Type’s PropertyInfo(s).  It would seem easier to just have a list of PropertyInfo(s) maintained within BusinessBase, similar to how the FieldManager works.  There is a lot of work done in PropertyInfoManager to link up the PropertyInfo being registered with the Type they belong to.

 

I am sure there is a reason for this and I just don’t see it or understand it enough.  I am just trying to learn more about CSLA and why things were built the way they were.

 

RockfordLhotka replied on Tuesday, March 01, 2011

Some of this is to deal with inheritance.

Consider that a class can define a property, and can then be subclassed by more than one other class.

The "leaf node" types have to create a consolidated list of properties for the type, including any from the base classes.

Those base class metadata objects (the PropertyInfo<T> objects) are not duplicated - they are reused. And this means they need to have the same offset index values into the managed backing field lists for every leaf type.

So that covers some of the information stored in the static property info management system.

Then there's the actual field manager for each business object. This field manager object contains the real managed field values unique to the business object instance - but based very much on the static propertyinfo metadata stored in the static property info manager.

Copyright (c) Marimer LLC