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

Answer 1

You could also name the interface IUserAccountManager (this convention is used in Eclipse RCP, for instance) and then use UserAccountManager for the default implementation.

Answer 2

Spring itself gives interfaces generic names and then names the classes based on the details of the implementation. This is one example that comes in mind:

interface: Controller
abstract classes: AbstractController, AbstractCommandController, 
                  SimpleFormController, MultiActionController

I don't think names like SimpleUserAccountManager or UserAccountDbManager are stupid, since they convey some information regarding the implementation of the manager/service.

What I find stupid is the common convention to add the "Impl" suffix at the implementation classes:

my/package/UserAccountManager
my/package/impl/UserAccountManagerImpl

Some people prefer this though.

Answer 3

To me a service class is about implementing a use case, so I name it according to what kind of user the service is acting on behalf of. So if I have an application with different roles, say Customers, Order Fullfillment people, Data entry people, and Admins, then I'd likely have a CustomerService, an OrderFulfillmentService, a DataEntryService, and an AdminService. I think naming a service according to the kind of data being fetched or twiddled is an anti-pattern. So guessing that UserAccount manipulation would be the domain of an Administrator I would probably call it "AdminService".

Answer 4

Related to the difference between managers and services: I would say use one layer for the business logic (service layer OR manager layer) for as long as possible.

As soon as that layer gets complicated (assume you used services) you can add managers with the responsibility of delegating to one service or another, but keep the business logic inside services.

So I would keep services simple, use managers to manage services, and keep the business logic inside services.

I also agree with avoiding the Impl suffix for implementations and avoiding the I suffix for interfaces. As an example, naming the interface "Controller" and naming the implementation "SimpleController" or "UserController" sounds better for me.

Answer 5

Assuming these are for REST services, I think your URI naming convention is more important than the name of the underlying implementation services, since the latter will be largely invisible to clients. Of course you want consistent naming internally, but it is not as crucial.

Some REST guidelines we have used: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (my blog)

Answer 6

I feel that the Service vs. Manager naming suffix is purely a preference. The only time where "Service" has ever cause confusion for us is when we also have Web services sitting on top of our service layer. On some projects, we simply referred to the Web service classes as brokers as all they did was serve to translate or broker the Web service call into a call to our service tier.

I agree with kgiannakakis that suffixing your implementations with "Impl" is not a good approach. I have also come across coding best practices that mention not to do this. Naming the interface after the abstraction is the generally accepted best practice. Naming the implementation class after the interface with some indicator of its purpose or type, as kgiannakakis suggested, seems to be the generally accepted approach.

When we have Web service based DAOs and ORM based DAOs, we use both packages and class names to differentiate the implementation classes from their interfaces and each other. I think putting the implementations in different packages comes down to how many classes you have in the package, how differently they are implemented, and how much you desire to split things up.