代码之家 › 专栏 › 技术社区 › Vasil

您对SpringMVC应用程序中的服务层使用什么命名约定?[关闭]

spring-mvc naming-conventions spring java

Vasil · 技术社区 · 15 年前

我一直在为Spring应用程序中的服务层制定一个好的命名约定。对于服务层中的每个类,我首先编写它应该实现的接口,然后编写实际的类。例如,我有以下接口:

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

然后是实现类…

这里让我恼火的是,UserAccountManager是实现类的好名字,所以我不得不给它起一个愚蠢的名字,比如SimpleUserAccountManager或UserAccountDBManager。到目前为止,您使用了哪些约定?把实现类放在不同的包中,并给它们与接口同名,这是一个好主意吗? 另外,您对使用以经理结尾的名称而不是以服务结尾的名称有什么看法?

9 回复 | 直到 12 年前

kgiannakakis 15 年前

Spring本身提供接口通用名,然后根据实现的细节命名类。这是一个考虑到的例子:

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

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

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

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

不过,有些人更喜欢这样。

David Rabinowitz 15 年前

我们使用的是:

XXXDAO(数据访问对象) - 负责直接与EntityManager、JDBC数据源、文件系统等交互。应只包含持久性逻辑,如SQL或JPA-QL,而不包含(或尽可能少)业务逻辑。只能从经理处访问。
XXXME管理器 - 在业务级别管理实体,通常执行CRUD操作,但添加所需的业务逻辑。
XXXService - 业务逻辑所在的层。应该尽可能多地用简单的对象“说话”——字符串、整数等。
XXX控制器 - 用户界面交互层。只应与服务部门通话。
XXXutilities/XXXutils公司 - helper无状态方法不应依赖于系统中的任何服务。如果需要这样的独立性,可以将实用程序类转换为服务,或者将服务结果作为参数添加。

对于实现,我们添加impl后缀(xxxserviceimpl),将其与接口区分开来,如果有多个实现,或者我们想要添加额外的信息,我们将其添加为前缀(jdbcxxxdaoimpl、googlemapsgeocodingserviceimpl等)。类名称在这种方式下会变得有点长,但是它们非常具有描述性和自记录性。

skaffman 15 年前

对于您给出的示例,我将使用反映怎样类执行操作,如HibernateUserAccountManager、JPauserAccountManager或JDBCUserAccountManager等,或者可能仅执行UserAccountManagerDao。

The Dag 14 年前

显然,类名以manager或service结尾本身并不重要。重要的是,一般来说,名字准确地表达了被建模的东西。这就是问题的关键:“服务”或“管理者”不是我们在软件对象中尝试模型的真实对象。相反,它们是我们收集一系列方法的地方,这些方法做的事情根本不符合我们的任何对象的职责。做需要/想要建模。

我个人更喜欢“服务”,但仅仅是因为“管理者”看起来像是一个可以实际建模的东西,也就是说,我们的“-manager”对象可能代表现实世界中的管理者。但这一点完全是学术性的,我立即承认,它没有任何实际意义。

真正重要的通常远比这些细枝末节更为基础:拥有一个被所有参与开发的人都很好理解的模型。如果说我的经历有什么可借鉴的,那就很少了。因此,我建议那些问“经理”或“服务”是否是正确的比喻的人:抛开一枚硬币,确保每个人都了解会议,花时间思考和讨论重要的事情!

DavidValeri 15 年前

我觉得服务 VS 经理命名后缀只是一个首选项。唯一一次“服务”给我们带来混乱的是,我们的服务层上也有Web服务。在一些项目中,我们只是将Web服务类称为代理,因为它们所做的只是将Web服务调用转换或代理为对我们的服务层的调用。

我同意Kgiannakaki的观点,用“impl”覆盖您的实现不是一个好方法。我也遇到过编写最佳实践的方法,它们没有提到要这样做。在抽象之后命名接口是公认的最佳实践。正如Kgianakakis所建议的那样,在接口后用其用途或类型的一些指示器命名实现类似乎是一种普遍接受的方法。

当我们有基于Web服务的DAO和基于ORM的DAO时,我们使用包和类名来区分实现类与其接口以及彼此之间的区别。我认为将实现放在不同的包中取决于包中有多少个类,它们的实现方式有多不同,以及您希望将内容拆分的程度。

Ilya Boyandin 15 年前

还可以命名接口iuseraccountmanager(例如,该约定用于EclipseRCP),然后使用useraccountmanager进行默认实现。

Nathan Hughes 14 年前

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

Anghel Contiu 12 年前

与经理和服务之间的差异相关: 我会说,尽可能长时间地使用一个层作为业务逻辑(服务层或管理层)。

一旦这一层变得复杂(假设您使用了服务),您就可以添加负责委派给一个或另一个服务的管理者,但将业务逻辑保留在服务中。

因此,我将保持服务简单,使用管理器来管理服务,并将业务逻辑保持在服务内部。

我也同意避免 实现的impl后缀并避免 接口后缀。例如,将接口命名为“controller”,将实现命名为“simplecontroller”或“usercontroller”对我来说更合适。

Andrew Barber Tejas Tank 12 年前

假设这些是针对REST服务的,我认为您的URI命名约定比底层实现服务的名称更重要,因为后者在很大程度上对客户机是不可见的。当然,您希望在内部保持一致的命名,但这并不是那么重要。

我们使用的一些休息指南: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (我的博客)