-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
是否考虑对 MVC 进行增强并解耦? #2847
Comments
Good idea! At present, I also have some thoughts in this regard. The code written in this way is clearer, rather than mixing exceptions and business together. Better decoupling between codes. |
想法特别不错,可作为快速开发业务系统的模板,如果能搞出来也是大功一件,但是每个公司都众口难调,特别像异常控制需求各异,怎么收敛起来,其实,存在难度的 |
因此我的观点是让工程师秉持预期和非预期的思想进行抛出异常,预期就是工程师手动抛出来的;非预期就是意料之外发生的。这样就避免了流水线似的用 try / catch 层层封装。就像生活中丢垃圾,我们只用关心垃圾的种类,而不需要在垃圾上还写上相关的信息。 |
如果可以尝试,请问我能认领该任务吗? |
Spring Boot 无侵入式 实现API接口统一JSON格式返回 |
感谢答复,关于该篇 Issue 中提到的功能我都在个人仓库 utility-framework 实现并做到了解耦。 |
hello @RovingSea , 不可行的,你的全局拦截器会让项目崩溃的,你尝试一下Controller方法返回 Output试一下,世界的大门会为你打开的。 |
感谢提问,再此是为了提出上述架构,为了避免刷屏,欢迎您来我的项目提Issue和PR。 |
前言
这个问题在 cloud 社区讨论视乎不太合适?但我发现 web&boot 社区并不活跃,借此占个楼。
问题描述
在企业项目开发中,spring-boot 对于 java 开发者来说已经是密不可分,但是多数中小型企业在开发 web 应用时缺乏基本的业务架构意识。据我所知,许多开发者对于 Controller 模块具备增加参数校验、全局异常捕捉以及封装模板统一响应功能的意识,少部分会使用公司内部依赖以覆盖上述功能。
即便如此,我发现这些开发者们虽然具备这样的功能意识,但是视乎也是因为要做参数校验而去做参数校验,要做异常捕捉而去做异常捕捉······导致对 Controller 模块做了许多重复工作,其架构如下图所示:
如上图所示,每个 Controller 的每个方法都需要进行重复的两步操作——参数校验和封装模板统一响应,以及对外抛出异常时基于业务认知进行异常捕捉。
愿景
进而我认为对 Controller 进行增强时,需要进行解耦,其架构如下图所示:
好奇促使
接着我怀着好奇之心探索存在如此做法的脚手架,但是都没有发现,随后在业余时间,我开发了一款简陋版,对比效果图如下:
普遍做法
新的做法
Controller
Validator
Response 统一配置
共建与普及
本人调研了本校同学与公司同事,对于此框架表示期待,借此想向阿里社区的前辈赐教:
The text was updated successfully, but these errors were encountered: