1

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.

P B
  • 650
  • 1
  • 7
  • 10

1 Answers1

0

There are two major reasons I can see to do this:

1) Thread safety - the PropertyInfoManager class is basically a static wrapper around a Dictionary which allows you to register PropertyInfo(s) for a Type and Get the PropertyInfo(s) for a Type. It handles the locking to ensure thread safety.

2) N-Level Undo - this feature of CSLA adds a lot of complexity to storing field values, the protected FieldManager is responsible for maintaining values of all managed backing fields for a BusinessBase. To do this the FieldDataManager class needs access to the PropertyInfo(s) of the type so having these in one place instead of passing some List around from the BusinessBase is a better approach.

In this case the FieldDataManager and PropertyInfoManager classes add modularity and I'm sure were influenced by Separation of Concerns (SoC) and the Single Responsibility Principle (SRP) when designed.

I am also learning about CLSA and in doing so have learned quite a bit about Object Oriented Design from the framework itself. I would recommend The Book and reading The Source Code to continue to learn more about CSLA .Net.

Joel Briggs
  • 1,779
  • 2
  • 14
  • 17