Java 您对 Spring MVC 应用程序中的服务层使用什么命名约定？

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

提问by Vasil

I'm stuck with figuring out a good naming convention for the service layer in a spring application. For each class in the service layer I first write the interface it should implement and then the actual class. So for example I have the following interface:

我一直在为 spring 应用程序中的服务层找出一个好的命名约定。对于服务层中的每个类，我首先编写它应该实现的接口，然后编写实际的类。所以例如我有以下界面：

public interface UserAccountManager{
   public void registerUser(UserAccount newUserAccount);
   public void resetPassword(UserAccount userAccount);
...
}

And then the implementation class...

然后是实现类...

What bugs me here is UserAccountManager is a good name for the implementation class so I'm forced into giving it a stupid name like SimpleUserAccountManager or UserAccountDbManager. What are some of the conventions you've used so far? Is it a good idea to put the implementation classes in a different package and give them the same names as the interfaces? Also what are your thoughts on using names ending with Manager over names ending with Service?

这里的问题是 UserAccountManager 是实现类的一个好名字，所以我被迫给它一个愚蠢的名字，如 SimpleUserAccountManager 或 UserAccountDbManager。到目前为止，您使用了哪些约定？将实现类放在不同的包中并为它们指定与接口相同的名称是否是个好主意？另外，您对使用以 Manager 结尾的名称而不是以 Service 结尾的名称有何想法？

采纳答案by kgiannakakis

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:

Spring 本身给出接口通用名称，然后根据实现的细节命名类。这是一个想到的例子：

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.

我不认为像 SimpleUserAccountManager 或 UserAccountDbManager 这样的名字是愚蠢的，因为它们传达了一些关于管理器/服务实现的信息。

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

我觉得愚蠢的是在实现类中添加“Impl”后缀的常见约定：

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

Some people prefer this though.

不过有些人更喜欢这个。

回答by DavidValeri

I feel that the Servicevs. Managernaming 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.

我觉得Servicevs. Manager命名后缀纯粹是一种偏好。“服务”唯一让我们感到困惑的时候是我们的服务层之上还有 Web 服务。在某些项目中，我们简单地将 Web 服务类称为代理，因为它们所做的只是将 Web 服务调用转换或代理为对我们的服务层的调用。

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.

我同意 kgiannakakis 的观点，即为您的实现添加“Impl”后缀并不是一个好方法。我还遇到过提到不要这样做的编码最佳实践。在抽象之后命名接口是公认的最佳实践。正如 kgiannakakis 所建议的那样，在接口之后命名实现类并带有其目的或类型的一些指示符，这似乎是普遍接受的方法。

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.

当我们拥有基于 Web 服务的 DAO 和基于 ORM 的 DAO 时，我们使用包和类名来区分实现类与其接口和彼此。我认为将实现放在不同的包中归结为包中有多少类，它们的实现方式有多么不同，以及您希望拆分多少。

回答by skaffman

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

对于您给出的示例，我将使用反映类如何执行操作的实现名称，例如 HibernateUserAccountManager、JPAUserAccountManager、JDBCUserAccountManager 等，或者可能只是 UserAccountManagerDAO。

回答by Ilya Boyandin

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

您还可以将接口命名为 IUserAccountManager（例如，此约定用于 Eclipse RCP），然后使用 UserAccountManager 作为默认实现。

回答by David Rabinowitz

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.

• XxxDAO（数据访问对象）- 负责直接与 EntityManager 、JDBC DataSource 、文件系统等交互。应该只包含持久化逻辑，例如 SQL 或 JPA-QL，但不包含（或尽可能少）业务逻辑。只能从经理访问。
• XxxManager- 在业务层面管理实体，通常执行 CRUD 操作，但添加所需的业务逻辑。
• XxxService- 业务逻辑所在的层。应该尽可能多地用简单的对象——字符串、整数等——“说话”。
• XxxController- UI 交互层。应该只与服务联系。
• XxxUtilities/XxxUtils- Helper 无状态方法，不应依赖于系统中的任何服务。如果您需要这样的 sependency，请将实用程序类转换为服务或将服务结果添加为参数。

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.

对于实现，我们添加了 Impl 后缀 (XxxServiceImpl)，以将其与接口区分开来，如果有多个实现或我们想添加其他信息，我们将其添加为前缀（JdbcXxxDaoImpl、GoogleMapsGeocodingServiceImpl 等）。这样类名会变得有点长，但它们非常具有描述性和自我记录性。

回答by The Dag

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 doneed/want to model.

类名以Manager 还是Service 结尾显然本身并不重要。一般来说，重要的是名称准确地传达了正在建模的内容。这就是问题的症结所在：“服务”或“管理器”不是我们尝试在软件对象中建模的真实世界对象。相反，它们是我们收集一堆方法的地方，这些方法做的事情根本不适合我们确实需要/想要建模的任何对象的职责。

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!

真正重要的通常比这些细节要基本得多：拥有一个所有参与开发的人都能很好地理解的模型。如果我的经验是可以借鉴的，那么这种情况很少发生。因此，对于那些询问“经理”或“服务”是否是正确比喻的人，我的提示是：掷硬币，确保每个人都了解公约，并花时间思考和讨论重要的问题！

回答by Nathan Hughes

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".

对我来说，服务类是关于实现一个用例，所以我根据服务代表的用户类型来命名它。因此，如果我有一个具有不同角色的应用程序，比如客户、订单完成人员、数据输入人员和管理员，那么我可能会有一个 CustomerService、一个 OrderFulfillmentService、一个 DataEntryService 和一个 AdminService。我认为根据获取或处理的数据类型来命名服务是一种反模式。因此，猜测 UserAccount 操作将是管理员的域，我可能会称其为“AdminService”。

回答by Robert Morschel

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.

假设这些用于 REST 服务，我认为您的 URI 命名约定比底层实现服务的名称更重要，因为后者在很大程度上对客户端是不可见的。当然，您需要内部一致的命名，但这并不重要。

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

我们使用的一些 REST 指南：http: //soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html（我的博客）

回答by Anghel Contiu

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 Isuffix for interfaces. As an example, naming the interface "Controller" and naming the implementation "SimpleController" or "UserController" sounds better for me.

我也同意避免在实现中使用Impl 后缀并避免在接口中使用 I后缀。例如，将接口命名为“Controller”并将实现命名为“SimpleController”或“UserController”对我来说听起来更好。