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

Question

我坚持在spring应用程序中找出服务层的良好命名约定.对于服务层中的每个类,我首先编写它应该实现的接口,然后编写实际的类.例如,我有以下界面:

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

然后是实施类......

这里有什么问题,UserAccountManager是一个很好的实现类名称,所以我不得不给它一个愚蠢的名字,如SimpleUserAccountManager或UserAccountDbManager.你到目前为止使用了哪些约定？将实现类放在不同的包中并给它们与接口相同的名称是一个好主意吗？您还有什么想法使用以Manager结尾的名称而不是以Service结尾的名称？

Answer 1

这是我们使用的:

• XxxDAO(数据访问对象) - 负责直接与EntityManager,JDBC DataSource,文件系统等进行交互.应仅包含持久性逻辑,如SQL或JPA-QL,但不包含(或尽可能少)业务逻辑.只能从经理访问.
• XxxManager - 管理业务级别的entites,通常执行CRUD操作,但添加了所需的业务逻辑.
• XxxService - 业务逻辑所在的层.应该尽可能地在简单的对象 - 字符串,整数等中"说话".
• XxxController - UI交互层.应该只与服务部门联系.
• XxxUtilities/XxxUtils - Helper无状态方法,不应该依赖于系统中的任何服务.如果需要此类依赖性,请将实用程序类转换为服务或将服务结果添加为参数.

对于实现,我们添加了Impl Suffix(XxxServiceImpl),以使其与接口不同,如果有多个实现或者我们想要添加其他信息,我们将其添加为前缀(JdbcXxxDaoImpl,GoogleMapsGeocodingServiceImpl等).类名称变得有点长,但它们非常具有描述性和自我记录性.

Answer 2

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

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

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

我发现愚蠢的是在实现类中添加"Impl"后缀的通用约定:

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

有些人更喜欢这个.

Answer 3

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

Answer 4

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

就我个人而言，我更喜欢“服务”，但仅仅是因为“管理器”似乎是可以实际建模的东西，即我们的“-manager”对象可能代表现实世界的管理器。但这一点完全是学术性的，我立即承认它没有任何实际区别。

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