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

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

0

3个回答

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

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

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

1

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

0
l523115401
l523115401 封装类?不太明白,这是要从request取数据的,封装类里把数据写进去?
4 个月之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
规范你的代码编写风格
笔者寄语:一份编写规范的代码会让人赏心悦目,养成良好的代码编写习惯是每一个程序员应该具备的基本素养!1、基本规则【规则1-1】标识符应当直观且可以拼读,可望文知意,不必进行“解码”。例如:标识符最好采用英文单词或其组合,便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂,用词应当准确。例如不要把CurrentValue写成NowValue。【规则1-2】标识符的长度应当符合“m...
MVC引入SERVICE层 提高代码重用性 沟通CONTROL和MODEL
MVC是web开发中常见的程序结构。 简单的mvc结构如下: view层:显示层。  control层:业务层,集合了各种action。  model层:模型层,一般和数据打交道。简单的sample:一个表对应一个model类。 其中control层调用model层的方法,实现对数据的访问。  采用这样的结构在一定程度上,可以做到代码清晰,较容易扩展
(精)分包原则/包的设计原则/组件(包)设计原则
组件,或者叫程序集,是指一种能够被独立部署的二进制单元,一般是以DLL的形式存在的。针对大型的软件系统,良好的组件设计能够把系统分解为一些小的组件,从而使每个开发团队都可以只关注单个的组件而无需关心整个系统。组件设计需要遵守如下原则: 重用-发布等价原则(REP)即重用粒度就是发布粒度。一个组件中的类要么都是可以重用的,要么就都不可以重用。 共同重用原则(CRP)一个组件中的所有类应该是共同重用的
MVC中三层规范写法示例
经常会在web项目中用到MVC模式的写法C:控制层Controller,负责对请求的url分发到不同的网址,处理请求的入口。 M:规范数据数据成Bean,并负责调用数据库 V:只负责从数据库获取数据,并显示。此三层的设计充分得将数据显示与数据操作很好的分离开了,是一种极佳的面向对象的设计思路。下面把常见的MVC模式的规范写法总结如下:model:public class Question {
SpringMVC 控制层类的三种写法
第一种: @Controller //注解 public class TestController extends AbstractController{ @Override @RequestMapping("/index") //注解:路径名 protected ModelAndView handleRequestInternal(HttpServletRequest requ
SpringMVC的Contrller控制器层的三种写法
MVC框架是什么 模型-视图-控制器(MVC)是一个众所周知的以设计界面应用程序为基础的设计模式。它主要通过分离模型、视图及控制器在应用程序中的角色将业务逻辑从界面中解耦。通常,模型负责封装应用程序数据在视图层展示。视图仅仅只是展示这些数据,不包含任何业务逻辑。控制器负责接收来自用户的请求,并调用后台服务(manager或者dao)来处理业务逻辑。处理后,后台业务层可能会返回了一些数据在视图层展
spring mvc控制层(controller)接收参数的问题
当前端使用表单提交数据时主要有两种方法接收数据:1,将数据封装成类。调用类的get()方法                                                                                                 2,用request.getParameter()接收字符串 当前端使用ajax提交数据时主要有两种方法接收数据
菜鸟学习Spring——SpringMVC注解版控制层重定向到控制层
一、概述。        SpringMVC中界面请求Contorller1,Contorller1需要重定向到Contorller2中显示其他页面或者做一些业务逻辑,Spring中提供了这个功能利用“redirect:/”来进行重定向。 二、代码演示。 1、界面 Login.jsp <%@ page language="java" contentType="text/h
Spring的学习--SpringMVC的四个基本注解annotation(控制层,业务层,持久层)
SpringMVC中四个基本注解: @Component、@Repository、@Srevice、@Controller  看字面含义,很容易却别出其中三个: @Controller  控制层,就是我们的action层 @Service     业务逻辑层,就是我们的service或者manager层 @Repository  持久层,就是我们常说的DAO层  而@Component
C#代码规范 常用的代码编写规则
C# 代码规范中列举了c#编程中所涉及的所以代码编写规范 第一章 概述 4 规范制定原则 4 术语定义 4 Pascal 大小写 4 Camel 大小写 4 文件命名组织 4 1.3.1文件命名 4 1.3.2文件注释 4 第二章 代码外观 6 2.1 列宽 6 2.2 换行 6 2.3 缩进 6 2.4 空行 6 2.5 空格 6 2.6 括号 - () 7 2.7 花括号 - {} 7 第三章 程序注释 9 3.4 注释概述 9 3.2 文档型注释 9 3.3 类C注释 10 3.4 单行注释 10 3.5 注释标签 10 第四章 申明 14 4.1 每行声明数 14 4.2 初始化 14 4.3 位置 14 4.4 类和接口的声明 15 4.5 字段的声明 15 第五章 命名规范 16 5.1 命名概述 16 5.2 大小写规则 16 5.3 缩写 17 5.4 命名空间 17 5.5 类 18 5.6 接口 18 5.7 属性 (ATTRIBUTE) 19 5.8 枚举 (ENUM) 19 5.9 参数 19 5.10 方法 20 5.11 属性 (PROPERTY) 20 5.12 事件 21 5.13 常量 (CONST) 22 5.14 字段 23 5.15 静态字段 23 5.16 集合 24 5.17 措词 24 第六章 语句 26 6.1 每行一个语句 26 6.2 复合语句 26 6.3 RETURN 语句 26 6.4 IF、 IF-ELSE、IF ELSE-IF 语句 26 6.4 FOR、FOREACH 语句 27 6.5 WHILE 语句 27 6.7. DO - WHILE 语句 28 6.8. SWITCH - CASE 语句 28 6.9. TRY - CATCH 语句 28 6.10. USING 块语句 29 6.11. GOTO 语句 29 第七章 控件命名规则 30 7.1 命名方法 30 7.2 主要控件名简写对照表 30 第八章 其他 30 8.1 表达式 30 8.2 类型转换 30 附录一: 匈牙利命名法 31