Home/ Questions/Q 43943
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T15:34:29+00:00

In a recent project I have nearly completed we used an architecture that as

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

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

    • 0