Manager Classes?

Question

Im writing a .net webforms app. It has a number of classes, for example users, bookings etc. At the moment I have a number of manager classes, say bookingManager, that manage these classes. For example when creating a new booking, you call the add method in the bookingManager, and pass a booking. It then checks the booking is valid, checkis it doesn't conflict, and if it does not, adds it to the db. I have similar managers for the other classes, however ones such as the user manager don't do alot more than take the user and add to the DB. So my question is, is this the best way to be doing this sort of thing, or is there a pattern or method thats better suited to this?

Answer 1

There is nothing wrong with having manager classes, especially when they manage several different aspects of the system, such as the booking manager you mention. In that case you may not want the user to know about bookings, or bookings to know about users - but this will naturally depend on the specifics of your system.

1. The nice thing about managers is that it provides a central and logical place to store perhaps complicated logic which depends on multiple components. It also lets you use the data-classes as that and increase the cohesion of those classes.

2. The "less nice" thing about managers is that you have another component which will likely be reasonably tightly coupled to the other components in the system. You need to balance the pro's and cons of this and go for the architecture that makes the most sense for your application.

Answer 2

I think it is always better to implement a Save, Delete and Update method for such classes. A Manager class for such things is definitely overkill. Those methods implemented in your, say, Booking class could do the same validation and avoid any complications introduced by adding too many classes to your code.

Answer 3

as you describe it you are already using a pattern, the 3 Tier pattern :)

This states that in the application you should have your code into 3 tiers (as the name states):

1. Presentation Tier : Where you write the code to present your data (ASPx/winforms/etc)

2. Application Tier : where you place all your business logic (what you are doing with the Manager Classes)

3. Data Tier : Where you do the actual access to the database.

Following this pattern can be useful when, you have something like a client with multiple addresses the client is stored in one table and the addresses in another. In your presentation tier you just invoke a method in the application tier to save the client. In the application tier you will check your data and invoke two methods in the Data tier, one for saving the client one for saving the addresses.

Now if you have suppliers with multiple addresses you can use the same method in the Data tier to save them.

This will be useful if you have complex objects. however if most of your objects are just plain simple I would recommend that you think it over if this pattern is the right one for you.

http://en.wikipedia.org/wiki/Multitier_architecture

Answer 4

If manager is like a controller/Presenter between UI and Domain Classes I think it should be thin layer. It should contains s few lines of code. Then Domain Services or Service classes should take care of rest job. For example :

UI:

buttonClicked(Eventargs...)
{
   presenter.Save();
}

Presneter:

public void Save()
{
   bookingService.Save(view.Name,view.DateTime...)
}

Service :

public void Save(string name,DateTime dateTime...)
{
   //do operations or call repository/Dao classes to save
}

I can be overkill for small applications but for a big application I increases maintainablitiy. You can look at Domain Driven Design book and Domain Service clasess.