通常我们在做一套系统时,一个请求的流程大概是action(controller)->service->dao,这个流程很清晰,也很简单,但是在具体业务中我们可能需要不同的业务之间的配合使用,这时可能需要service中调用service。
例如AService中调用BService,BService中又调用CService,CService又调用AService,这样我们就造成了A中注入B,B中注入C,C中又注入A的循环注入情况,这时Spring在初始化时就出问题了。
在查询了一些资料中,基本上意见都是“这属于系统设计问题”,经过不断的思考,我想出一个解决办法,那就是我们在普通的三层设计中再添加一层(BusinessService),我们规定:
1,**Service层只面向单表(这里的单表指的是不注入其他service层,当然在写sql时仍然可以join其他表,不过返回结果就需要自定义一个dto来接收)**。
2,**若在service层只对数据库负责,要进行数据持久时,不校验数据的正确性,只校验数据是否为空,是否符合数据库的非空约束、是否符合数据库的索引约束等。**
若有比较复杂的业务(需要多个子业务支撑)时,我们在Business层中统一调用多个service层的方法,然后依次由BusinessService层进行组装和事务控制,举个例子:
我们现在有一个添加学生个业务,添加学生总共有3个子业务
1,保存学生基本信息
2,更新学生所在的班级学生数量
3,更新学生所在的学校的学生总数
那我们只需要在StudentBusinessService中依次注入StudentService、ClassStudentCountService、SchoolStudentCountService,并在StudentBusinessService中的add方法内依次调用这三个子业务的对应方法即可。
如此,这样A->B-C->A 就变成了 A-B,A-C(A层为BusinessService层,B、C为service层,service层永远不会调用BusinessService层,从而打破了之前循环结构) 从而解决了之前的问题了
但是,随着业务的增长,之前在BusinessService中定义的方法可能成为更大的一个业务中的一个子业务了,
举个例子,
教师在从一个校区调到另一个校区,此时需要将该教师原有的学生全部加入到现在的校区中(**此处为业务规定,不做合理性解释**)
那么也很简单,我们需要在TeacherBusinessService中注入StudentBusinessService即可,然后调用StudentBusinessService的add方法,然后add方法会调用其他子业务,但是这样可能又回到了之前的A->B-C-A的模式了,随着业务的增长,很可能又会出现循环注入的问题。
我暂时还没想出更好的解决办法,不知各位是如何处理类似的问题的?
慕姐8265434
胡子哥哥
MMTTMM
隔江千里
相关分类