标签：1.0 mvc框架 代码 基础 拦截器 职责 系统 存在 ring
一、背景
会员平台系统A提供基础的账户登录服务。业务系统B作为业务线的业务平台型系统承载各业务系统。
B及各业务系统j基于A提供的登录拦截器来进行登录态的判断。
由于B及各业务系统越来越多，各业务系统不需要感知系统A的存在，而是基于B来透传一个统一的业务平台登录框。
二、单一职责
V1.0
B系统基于A的底层拦截器封装一层业务平台型的拦截器，并将B之前的一些业务权限校验的逻辑也放到B的登录拦截器中。
1.0设计的出发点
各业务系统在B上透传，因此理所当然的遵守B的权限校验规则。
但是B既是业务系统也是其他业务系统的平台，各业务系统不应该与B的权限校验耦合。
2.0 优化
B的登录拦截器只提供统一的业务平台型的登录态校验，并做一些B系统的平台型的业务功能即可，将权限校验逻辑单独剥离到B系统的业务独有的拦截器中，
让B提供的登录拦截器保持单一职责~
三、可维护性
另外，B系统自身的拦截器是基于阿里自身的Webx框架，但由于部分新接入的业务系统基于SpringMVC框架，因此B需再提供一套SpringMVC的登录拦截器。
最初，简单粗暴将B已有的对外maven 二方包client jar 复制一份client-spring jar二方包，逻辑几乎一致，只是将Webx的valve改为SpringMVC的Interceptor
这种方式维护2份client jar并且代码逻辑几乎一致。
改进：只提供一份client jar。里面既提供Webx的Valve也提供SpringMVC的Interceptor。将登录的核心校验逻辑剥离成公共的部分，只保留Valve、Interceptor的不同部分。
后续如果有其他接入业务系统采用另一种不同的MVC框架，可快速扩展
标签：1.0 mvc框架 代码 基础 拦截器 职责 系统 存在 ring
原文地址：http://www.cnblogs.com/zxm-love/p/7276930.html
