将您的所有业务逻辑集中在一个地方会带来各种好处。它使您的逻辑清晰,易于调试。但是,我觉得在某些情况下它不能很好地扩展。
例如,
class Book{
String a, b......z;
}
我的书类有26个字段(通过z)。对于单独搜索,有2 ^ 26种可能的查询方式。
如果我要为此编写服务类(存储库):
interface BookRepo{
List<Book> findById(int id);
List<Book> findByA(String a);
List<Book> findTop10ByADescending(String a);
List<Book> findByBAndCAndDAnd....Z(String a, b, c,d, e....z);
....
}
正如你所看到的,这是荒谬的,因为有很多搜索变量组合可能,更不用说排序和可能出现在图片中的分页变量。
如果我的应用程序非常灵活,那么对于给定的“资源”,用户可以过滤任何字段,按任何方式排序。我不应该完全跳过服务层吗?
我尝试过写一个“通用”服务层,在静态类型语言中并不容易。此外,如果您的服务层现在可以通过,那么就没有必要。
答案 0 :(得分:1)
您的问题与现有vs缺少服务层无关。您的问题是由错误的数据结构和/或存储库设计引起的。
如果你想要按26个字母的所有可能组合进行过滤,那么考虑动态创建查询和/或在字母和书之间建立多对多的关系,而不是在书中有26个字段。那么你将拥有恒定和少量的存储库方法,你可以轻松添加新的字母。
如果您的应用程序不需要服务层,那么您不必添加它。但是如果你没有它并且你的应用程序越来越难以发现它需要它的那一刻。相反,人们倾向于将服务逻辑放入控制器和/或存储库中。特别是当你在团队中工作时