我有一个使用 spring/hibernate/jsp 标准堆栈和典型层的 Java EE 应用程序:
- @Repository(或 DAO)
- @服务
- @控制器
每个存储库都有许多 find... 方法(例如,对于 BookRepository:简单的 findById、findByTitle、findByAuthor、更复杂的 findMostUsed、findMostCommented 等)
服务层包含应有的业务逻辑调用存储库。
控制器调用服务方法并填充要在 JSP 中使用的 ModelAndView。
当然,服务中也有一些业务逻辑比较复杂的方法。但令人讨厌的是有很多像这样的愚蠢方法:
public List<Book> findMostUsed() {
return repository.findMostUsed();
}
public List<Book> findMostCommented (boolean includeRating) {
return repository.findMostCommented(includeRating);
}
...
所以它们只是一个简单的委托(这些查找方法中没有业务逻辑 - 存储库中的数据库查询完成所有选择和分组)。
如果我需要更改存储库中的方法,则服务也需要更改。经过 2 年的开发,无需为这些方法添加任何逻辑 - 仅更改了查询及其参数。
我看到了更糟糕的设计,人们创建了 Controller -> Facade -> Service -> Repository -> DAO,每一层都充满了这样的方法。
什么是更好的设计?
也许要删除所有这些方法并将服务转换为更通用(例如 BookPricingService、BookRatingService 等,而不是单个 BookService(这违反了单一责任原则顺便说一句)?然后控制器将调用 Service 和 Repository 层,这是不好的。
也许让 find 方法更通用,例如 findByCriteria(criteria) 以减少它们的数量。但问题是查询是如此不同,这将以一种 switch-case 块结束,该块根据条件类型选择正确的查询/参数。顺便说一句,Spring-Data 还建议每个带有 @Query 注释的查询使用一种方法。
也许这只是我们拥有抽象层应该付出的代价?