对于 Spring MVC 应用程序中的服务层，您使用什么命名约定？[已关闭]

naming-conventions java spring spring-mvc

2022-08-31 22:44:21

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

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

然后是实现类...

让我烦恼的是UserAccountManager是实现类的一个好名字，所以我被迫给它一个愚蠢的名字，比如SimpleUserAccountManager或UserAccountDbManager。到目前为止，您使用了哪些约定？将实现类放在不同的包中并为其提供与接口相同的名称是否是一个好主意？另外，您对使用以管理器结尾的名称而不是以服务结尾的名称有什么想法？

答案 1

以下是我们使用的内容：

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

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

答案 2

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

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

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

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

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

不过有些人更喜欢这个。