2 l523115401 l523115401 于 2018.07.11 20:58 提问

关于代码编写规范的疑问,spring mvc 控制层一段代码被多次复制重用,如何设计优化

业务逻辑大概如下:
功能:用户留咨保存功能
视图层:留咨界面,用户填写信息
控制层:校验数据合法,并依据request从cookies中取出用户城市站、usertraceId等信息,根据request请求头判断设备类型。最终封装实体调用入库接口。
服务层:验重、保存数据。
问题:
控制层做入参校验理所当然,没有问题。现在问题来了,此控制器承载多方留咨请求,,绝大部分业留咨务都可以直接请求,变化来了,在另一种业务条件下,如领优惠券,产品提了需求,要求用户领券成功之后在再调用用户留咨接口。我初始想在领券控制器中判断,成功后直接调用用户留咨控制器,避免一系列参数校验逻辑再写一遍,也不用再重写从request里面获取cookies等方法。但是考虑到mvc的设计,不应该控制层调取控制层(redirect除外)但是不调用,着一系列的逻辑我又要重写一份。又想到把校验逻辑和取cookies和设备信息放到service层,但是需要操作request,request是控制层操作的,如果把request带到服务端,那样也破坏了编码规范,至少这个服务类方法的test ng你都很难跑。不能new一个request对象吧。
所以不知道如何设计才好?难道我还是要把校验等代码复制一份?求探讨指教

3个回答

bayuemu
bayuemu   2018.07.11 21:10
已采纳

验证的事情交给拦截器去做

xiao_nini
xiao_nini uuu
2 个月之前 回复
qq_40959736
qq_40959736 验证的事情交给拦截器去做
2 个月之前 回复
l523115401
l523115401 想到了,在这个业务里使用不太适合。这个领券控制器是有逻辑的,只有在特定渠道调用的领券才会留咨,拦截器把领券请求也加上是不是显的不太合理呢,毕竟大部分领券是不需要留咨的。当然这只是一种情况
2 个月之前 回复
cangketie
cangketie 你好酷啊,都玩这个了
2 个月之前 回复
l523115401
l523115401 我想过用拦截器,方法可行,可是拦截器处理这种逻辑感觉怪怪的
2 个月之前 回复
javacaprain
javacaprain   2018.07.12 11:15

有几个办法:
1、如果Service层不想让request对象作为参数传入,可以在Controller层将request对象的参数放到ThreadLocal中,可以线程安全地传入Service层。
2、也可以采用创建工厂设计模式,动态地去获取对应的Service
3、也可以跳出MVC的范畴,往微服务靠一靠。比如说把现有的业务拆分成上下游两个服务,第一层服务是Controller,第二层服务是Service,两层服务间的调用。

qq_42214807
qq_42214807   2018.07.11 21:54

封装类 对其实例化或在放入配置文件中

l523115401
l523115401 封装类?不太明白,这是要从request取数据的,封装类里把数据写进去?
2 个月之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
规范你的代码编写风格
笔者寄语:一份编写规范的代码会让人赏心悦目,养成良好的代码编写习惯是每一个程序员应该具备的基本素养!1、基本规则【规则1-1】标识符应当直观且可以拼读,可望文知意,不必进行“解码”。例如:标识符最好采用英文单词或其组合,便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂,用词应当准确。例如不要把CurrentValue写成NowValue。【规则1-2】标识符的长度应当符合“m...
MVC中三层规范写法示例
经常会在web项目中用到MVC模式的写法C:控制层Controller,负责对请求的url分发到不同的网址,处理请求的入口。 M:规范数据数据成Bean,并负责调用数据库 V:只负责从数据库获取数据,并显示。此三层的设计充分得将数据显示与数据操作很好的分离开了,是一种极佳的面向对象的设计思路。下面把常见的MVC模式的规范写法总结如下:model:public class Question {
MVC引入SERVICE层 提高代码重用性 沟通CONTROL和MODEL
MVC是web开发中常见的程序结构。 简单的mvc结构如下: view层:显示层。  control层:业务层,集合了各种action。  model层:模型层,一般和数据打交道。简单的sample:一个表对应一个model类。 其中control层调用model层的方法,实现对数据的访问。  采用这样的结构在一定程度上,可以做到代码清晰,较容易扩展
(精)分包原则/包的设计原则/组件(包)设计原则
组件,或者叫程序集,是指一种能够被独立部署的二进制单元,一般是以DLL的形式存在的。针对大型的软件系统,良好的组件设计能够把系统分解为一些小的组件,从而使每个开发团队都可以只关注单个的组件而无需关心整个系统。组件设计需要遵守如下原则: 重用-发布等价原则(REP)即重用粒度就是发布粒度。一个组件中的类要么都是可以重用的,要么就都不可以重用。 共同重用原则(CRP)一个组件中的所有类应该是共同重用的
spring mvc 控制层梳理
言归正传,研究一下注解下的控制层。 我习惯于使用JSTL展示页面,因此需要在原lib基础上增加jstl.jar和standard.jar,详细lib依赖如下: 引用 aopalliance-1.0.jar commons-logging-1.1.1.jar log4j-1.2.15.jar spring-beans-2.5.6.jar spring-context-2.5.6.j
解决Controller臃肿问题
思路:controller里面就只应该存放这些不能复用的代码,这些代码1.初始化时,构造相应的view和model.2.监听model层的事件,将model层的数据传递到view.3.监听view层的事件,并且将view层的事件转发到model成.controller只有以上这些代码它的逻辑就非常简单了,而且非常短.controller进一步的解决方案但是,我们却很难做到这一点,因为还是有很多逻辑...
学习SpringMVC中优秀的代码编写风格
在org.springframework.web.servlet.FrameworkServlet 中有下面这段代码 private class ContextRefreshListener implements ApplicationListener<ContextRefreshedEvent> { @Override public void onApplic
SpringMVC的Contrller控制器层的三种写法
MVC框架是什么 模型-视图-控制器(MVC)是一个众所周知的以设计界面应用程序为基础的设计模式。它主要通过分离模型、视图及控制器在应用程序中的角色将业务逻辑从界面中解耦。通常,模型负责封装应用程序数据在视图层展示。视图仅仅只是展示这些数据,不包含任何业务逻辑。控制器负责接收来自用户的请求,并调用后台服务(manager或者dao)来处理业务逻辑。处理后,后台业务层可能会返回了一些数据在视图层展
MVC设计模式针对业务层和控制层代码分离的看法。
对于业务逻辑代码放在业务层,对于应用逻辑代码放在控制层 对于什么是业务逻辑,什么是应用程序逻辑: 示例: 用户点击商品的“添加到购物车”按钮,引起一次请求。服务器开始处理该请求,过程: 1、检查当前用户是否有权限(比如是否已经登录、用户帐户状态、是否可以购物等) 2、检查要添加的商品ID是否有效、 3、检查要添加的商品库存是否足够 4、将商品加入购物车,并保存购物车状态 5、反馈信
spring mvc防重复提交(第二种 自定义注解 以及 注解的实现 和 运用注解)
转载至 :http://blog.csdn.net/u013378306/article/details/52944780 第一种方法:判断session中保存的token比较麻烦,每次在提交表单时都必须传入上次的token。而且当一个页面使用ajax时,多个表单提交就会有问题。注解Token代码: [java] view plain copy print?package com.thinkgem.