views:

183

answers:

4
+1  Q: 

Manager classes

Hello all,

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.

+3  A: 

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).

Gilligan
+1  A: 

What are Code Smells? What is the “best” way to correct them?:

Presence of types whose names start\end with "Utility", "Helper" or "Manager"

[please don't kick me :)]

aku
I agree that it is generally a code smell. I see what you and stucampbell are getting at here.
Gilligan
A: 

Sounds like your motivation for that design was good - reuse of code. In some ways it is similar in motivation to Martin Fowler's Service Layer. However, you may be piling too many responsibilities into these Manager classes. Perhaps separate infrastructural concerns (WAP push, user persistence) from domain concerns (user registration). This Separation of Concerns would increase reusablity further and also improve maintainability.

stucampbell
A: 

stucampbell, although I am sending a WAP push and persisting the user in the UserManager all this logic isn't actually contained in this function i.e. The UserManager will call an instances of ISmsService and IUserMapper to perform the related task.

The manager classes basically just act as a the coordinator of all these related actions.

I accept that "Manager" is quite an ambiguous name, but I am not sold on Controller in this situation. Additionally, I am still unsure as to whether my approach was the correct one, naming conventions aside. The UserManager.RegisterUser() for example may look something like the following:

IUserMapper userMapper = ServiceFactory.GetService(IUserMapper);
User user = userMapper.Save(user);
if(user!=null) ServiceFactory.GetService(ISmsService).Send(this.GetRegistrationSms(user));

So aside from the fact that these classes are named "Manager" am I doing anything wrong by moving this coordination logic out of the web/service assemblies?

Owen
I edited my answer to what I think better answers your question.
Gilligan