Manager classes?
I am writing a .net webforms application. It has several classes like users, orders, etc. At the moment I have several manager classes, for example bookingManager, that manage these classes. For example, when creating a new booking, you call the add method in the booking manager and submit the order. Then it checks that the booking is valid, check if it conflicts, and if not, add it to the db. I have similar managers for other classes, however, such as the custom manager don't do more than take the user and add to the DB. So my question is, what is the best way to do this, or is there a pattern or method that is better suited for this?
source to share
as you describe it, you are already using a template, a level 3 template:
This means that in the application you must have 3 levels of code (as indicated in the title):
-
Presentation layer: where you write the code to present your data (ASPx / winforms / etc)
-
Application layer: where you put all your business logic (what you do with the manager classes)
-
Data layer: where you do the actual database access.
Following this pattern can be useful when you have something like a client with multiple addresses that the client stores in one table and addresses in another. In your presentation layer, you simply call a method in the application layer to persist the client. At the application level, you will validate your data and call two methods in the data engine, one to persist the client to persist addresses.
Now, if you have providers with multiple addresses, you can use the same method in the Data Layer to store them.
This is useful if you have complex objects. however, if most of your objects are just plain simple, I would recommend that you consider whether this pattern is right for you.
source to share
If the manager is like a Controller / Presenter between UIs and Domain Classes, then I think it should be a thin layer. It should contain multiple lines of code. Then the domain services or service classes have to take care of the work on vacation. For example:
interface:
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
}
it may be overkill for small applications, but for large applications it increases the supporting one. You can check out books on domain name design and drivers.
source to share
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 this case, you may not need the user to know about the reservation or the reservation in order to learn about the users, but this will naturally depend on the specifics of your system.
-
The good thing about managers is that it provides a central and logical place to store possibly complex logic that depends on multiple components. It also allows you to use data classes and increase the concatenation of those classes.
-
The less nice thing about managers is that you have another component that is likely to be tightly coupled with other components in the system. You need to balance the pros and cons of this and go for the architecture that makes the most sense for your application.
source to share
I think it is always better to implement Save, Delete and Update method for such classes. The manager class will definitely overdo it for such things. Those methods that have been implemented in your, say, booking class can perform the same checks and avoid any complications that come with adding too many classes to your code.
source to share