Hi All,

I'm having difficulties organizing what functionality goes into what Manager classes.

Some tables are simply lookup tables. What I was thinking for those is to create a LookUpMananger class. That class would return EntityCollections for each lookup table. I was then going to pass these EntityCollections to my other manager classes to use. So, does this sound reasonable? Also, does the EntityCollection have a method to quickly locate an entry in the collection by Primary Key or Uique Constraint? If not, should I return a hashtable or custom collection instead?

As far organizing Manager classes, is there any tips and tricks ?

My thinking is that you create functional areas and those become the Manager but it does not seem that clear cut.

Also, should I create classes that just create entity collections that will be used in the Manager classes?

Thanks,

Fishy.

Fishy wrote:

As far organizing Manager classes, is there any tips and tricks

I think organizing responsibilities into classes is the key aspect of object oriented development. It is the part of software development that requires the hardest thinking. You are probably not looking for tips and tricks but for a strategy to guide this process.

At the top level i usually start to make a distribution into broad areas (layers) like presentation, business logic, technical infrastructure (DAL, logging, ...). Manager classes can be present in all areas: use case controllers in the presentation layer and manager classes in the business logic layer.

Then i try to find for each area a driving force to organize its responsibilities. This depends on the type of system being build. In task oriented systems i want the manager classes to map as closely on the business proceses as possible. In more presentation oriented systems i tend to organize the manager classes on sets of related entities. Other aspects that drive the assignment of responsibilities to manager classes are autorization and ownership of the data.

In dividing the functionality to the manager classes there will be cases where it not clear what class it should belong to. What has worked for me in this cases is to apply the information expert pattern and the creator pattern as much as possible (google for GRASP patterns).

What I was thinking for those is to create a LookUpMananger class. That class would return EntityCollections for each lookup table. I was then going to pass these EntityCollections to my other manager classes to use. So, does this sound reasonable?

You always end up with some entities for lookup tables, so it's a reasonable thing to do. I would name it a LookupTableManager since it manages LookupTables, not lookups.

Also, does the EntityCollection have a method to quickly locate an entry in the collection by Primary Key or Uique Constraint? If not, should I return a hashtable or custom collection instead?

If the entity has a single column PK, you can use the EntityCollection's Find method. IMO there is no reason why you should return a hashtable or custom collection because the EntityCollection misses the method. There must be a separate reason to maintain an additional datastructure.

Thanks for your thoughts on this.

Fishy