What naming convention do you use for the service layer in a Spring MVC application? [closed]

Answer 1

It's obviously not important in itself whether class names end in Manager or Service. What's important, generally speaking, is that names accurately convey what is being modeled. And that's the crux of the problem: "Services" or "Managers" aren't real-world objects that we try model in our software objects. Rather, they are places where we collect a bunch of methods that do stuff that simply doesn't fit in with the responsibilities of any of the objects we do need/want to model.

Personally I prefer "service", but only because "manager" seems like something one could actually model, i.e. there could be real-world managers that our "-manager" objects represent. But the point is entirely academical and I immediately concede that it makes no practical difference whatsoever.

What really matters is usually far more basic than such fine points: To have a model that is well understood by all involved in development. If my experience is anything to go by, that is seldom the case. My tip to those asking if "manager" or "service" is the right metaphor is therefore: Flip a coin, make sure everyone knows about the convention, and spend your time pondering and discussing matters that matter!

Answer 2

Here is what we use:

• XxxDAO (Data Access Object) - Responsible for interacting directly with the EntityManager , JDBC DataSource , file system, etc. Should contain only persistence logic, such as SQL or JPA-QL, but not (or as little as possible) business logic. Should be accessed only from Managers.
• XxxManager - Manages entites at the business level, usually performs CRUD operations, but adds the required business logic.
• XxxService - The layer where the business logic resides. Should "speak" in simple objects - Strings, ints, etc. - as much as possible.
• XxxController - The UI interaction layer. Should speak to Services only.
• XxxUtilities/XxxUtils - Helper stateless methods, should not depend on any service in the system. If you need such sependency, either convert the utility class to a service or add the service result as a parameter.

For the implementation we add the Impl Suffix (XxxServiceImpl), to distinct it from the interface, and if there are several implementations or we want to add additional information we add it as prefix (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl, etc.). The classes names become a bit long this way, but they are very descriptive and self documenting.

Answer 3

For the example you give, I would use implementation names that reflect how the class performs the operations, like HibernateUserAccountManager, or JPAUserAccountManager, or JDBCUserAccountManager, etc, or perhaps just UserAccountManagerDAO.