So it appears that I have some FxCop messages to correct.
On my parent classes (not many, but some) I had some protected member variables. The descendent classes execute the stored procedure and accomodate the population of members for not only itself but its parents.
According to FxCop, this is bad. It does not like the fact that my ancestor classes are using protected member variables. Presumably, this is because I could create descendant classes from other libraries and tinker with the implementation of the ancestor classes. OK, I get that.
The options are - make the ancestor classes' members private or internal.
With the latter (internal), then all of my code compiles just fine and I can move along happily. Ideal? Of course not - I can break encapsulation among the other classes with the library.
So what of making them private? Then I'm reliant upon the child classes to pass along the data reader to the parent in order for the parent to hydrate themselves, pass along the command object in order for the parent to add the necessary parameters for inserting and updating as necessary.. obviously the parent has to be more of a conductor of data access.
Has anyone run into this conundrum and made a decision they were most comfortable with? I can only assume the way to eventually go is to make the abstract ancestor classes only exhibit private members and not protected members and deal with any repurcussions that come forth as a result of that.
Thanks!
Chris
You terminology is a bit confusing.
Especially where you refer to Parent and Child classes.
These have special meanings in CSLA and are of 2 different Types.
But then you refer to protected memeber variabels and ancestor classes. So let's assume you are talking about an inheritance hierarchy.
If you have an Abstract base class (MustInherit in VB) then derive a concrete class from it, the question seems to be - should I have Protected member variables or not. I can see from a purist point of view that you might want to change them to Private and then deal with the repercussions. But for my CSLA BOs, the only reason I have an Inheritance hierarcy is so that I can code gen my base class and then hand code any other features in the derived class. This allows me to re-generate my base classes without fear of losing changes. Based on this usage - I think Protected memeber variables are fine and so is their direct use in the derived class.
Joe
Sorry about that - I realize my message wasn't entirely clear - I am indeed talking about the inheritance hierarchy.
That's generally how I feel too, though I feel like there is some value in really trying to adhere to FxCop and after reading the article on why protected might not be the best route, I may pursue it at some point. I modified my templates to generate my inheritence hierarchy and can probably make modifications at some point.
But thanks for your input, Joe.
Copyright (c) Marimer LLC