When do I call my class controller, manager or service?
JavaModel View-ControllerArchitectureNaming ConventionsJava Problem Overview
Maybe it is obvious to you. I'm new to java (half year work) and I had a discussion with my collegues. I have troubles naming my classes according to their responsibilities. For that, my classes gain responsibilities they should never have.
Can you help me?
BTW: I'm working current at a project where I have to use a persistance-layer from service classes. I have split my packages to model, service and persistance.
Java Solutions
Solution 1 - Java
There are certain patterns and guidelines behind these term, which is where I usually base it on:
Controller is based on the Model-View-Controller design pattern and should be used explicitly for the classes that implement the controller functionality based on this design pattern. E.g. if you are using Spring MVC and you extend from one of the Controller classes.
Service is a little less specific, but I recommend basing the implementation on the Service Layer pattern from "Patterns of Enterprise Application Architecture". Basically where a controller is more platform specific (e.g. transport via HTTP and rendering of Hypertext, usually HTML for web based controllers) a service shouldn't have to know about who is using it and how. You are just providing a uniform interface that can be used in turn by e.g. a web controller.
Managers well... manage stuff. Connections, application context, sessions; usually as a central location where components throughout the application can talk to.
Solution 2 - Java
To add to the good answers already given, if you find that you have a hard time finding a suitable name for your classes, then maybe you should investigate if your classes have more than one responsibility. If this is the case, then you should definitely refactor your code to isolate responsibilities into separate classes.
Solution 3 - Java
For naming convention please read the official convention.
Manager - As the name suggest which manages things in your code like EntityManager, it manages Entities, TransactionManager - It manages transaction. So you can have something called as SecurityManager which manages which Algo to use for encryption e.t.c
Controller - Again name speaks a lot, controls how what needs to be done, or how things to be done. For e.g. ActionController - takes care of what to do on receiving user action event
Service - Consider it something like postalService, a task performed by someone on a general note, you can make use of it.
Packaging code needs lots of thinking, your application packaging should always align to the business model which it is catering to.
Along with business model then you need to think if the feature is very much at heart of the application so you will move it to the core, say if the feature is for talking to other application you would like to move it under integration and so on.
Solution 4 - Java
I do not know if I ever named a class manager so I'll leave it out.
For me controller is something controlling or deciding where should something (signal, message,..) go.
Service is an interface (and implementation of that interface) providing some functionality, usually at the border of system or sub-system. Hides implementation details as much as possible.