Manager classes

Question

In a recent project I have nearly completed we used an architecture that as its top layer of interaction from the web/services layers uses XXXManager classes.

For example, there is a windows services that runs on a scheduled basis that imports data from several diverse data sources into our system. Within this service several "Manager" classes are called i.e. CPImportScheduleManager, CPImportProcessManager etc..

Now these Manager classes do a lot more than just pass method up the chain for use in the web/service layers. For example my UserManager.Register() method doesn't just persist the user via lower level assemblies but it also send a WAP push to the user and determines the mobile handset used etc.

It has been suggested to me that this type of architecture I a common means of trying to get OOP to fit into a procedural model. I can see their point here, but what I am wondering is with this top level set of classes any web/service layer can simply call the same common method without having to rewrite code. Thus if I wanted to write a web service that at some point registered a user I could again just call the UserManager.Register() method without having to rewrite all the logic again.

I never have been the best person to explain myself, but if my ramblings make sense please feel free to advise on your alternatives.

Cheers, Chris.

Answer 1

Managers are a commonly overused naming strategy for services that handle the workflow or complex tasks for a given set of entities. However, if it gets the job done, then it is not necessarily a bad thing.

The important question I would have is what is going on underneath the managers? IF they are simply coordinated the workflow of a process, such as registering a user, then they are controllers (MVC) with a different name. However, if they are containing a lot of business logic (by this I mean conditional logic depending on the state of an entity or set of entities) then I would take a careful look to see if you can make this logic explicit by making it its own class or moving it to the class with the proper responsibility.

Update: From the sound of it, you have right idea in general. You have a set of classes that handle the coordination of your business processes that do not care whether they are being used by a WebService, a Webform, or whatever. Then you are saying you want to add your WebService layer on top of this and utilize these classes. This is a Good Thing(tm).