通过改造之后,感觉Controller层与Service层合并了,这样感觉不是很好啊?

通过改造之后,感觉Controller层与Service层合并了,这样感觉不是很好啊?

原先的@Service标准的类变成了@RestController了,并且其业务实现还在,这不就是合并了吗?可不可以这样,原先的Service、ServiceImpl等不要动,另外再新增Controller的接口类(API)和Controller的实现类(Impl),然后再去调用Service,这样不仅没有合并了,而且还没有破坏MVC的模式啊。

正在回答 回答被采纳积分+1

登陆购买课程后可参与讨论,去登陆

1回答
Java架构师讲师团 2020-04-08 20:19:33

其实微服务里没有“controller”这个概念了,这里保留的controller是为了兼容以前的老代码。微服务上下游关系都直接面向服务本身,返回按照json格式,不用再封装视图层

  • 按照以上回复 是不是说 controller 层只是为了兼容旧代码 如果我是从零直接搭建微服务 就不用 controller 层了 直接写 service 层 然后前端页面也直接访问 service 层 请问这样理解对吗 谢谢
    2020-10-16 16:13:47
  • 还是说 service 层的代码只是给微服务之间调用使用的 就是给 feign 调用 不提供给前端直接调用?
    2020-10-16 16:17:44
  • CEO_ZKF #3

    同问老师问题:


    这个Service 在这个项目里改造,好像依赖性高吧,也有感觉不安全,如果 Service 是对外提供给微服务,那么内部调用也在使用,例如 Swagger Api 的RestController 这一层也在使用 Service,这似乎偶合性了,对外来说,并不安全吧, Service 里面写了内部自己私有的业务逻辑,而且还是接口约束实现,外部(其他团队)也能调用我自己内部需要的业务逻辑吗?还是说,以后都不使用Swagger 这一层Controller



    @FeignClient("foodie-item-service")

    @RequestMapping("item-api")

    public interface ItemService {


      ?? 是否加入 @GetMapping 之类的注解供调用?

      public void 服务自内部调用使用(Map mapPrama){  ... }



    }


    2021-05-28 20:35:54
问题已解决,确定采纳
还有疑问,暂不采纳

恭喜解决一个难题,获得1积分~

来为老师/同学的回答评分吧

0 星
请稍等 ...
意见反馈 帮助中心 APP下载
官方微信

在线咨询

领取优惠

免费试听

领取大纲

扫描二维码,添加
你的专属老师