MVC框架的映射和解耦
<pattern>/*</pattern>
</decorator>
<excludes>
<pattern>/admin/*</pattern>
</excludes>
这样一来，所有的请求（除了匹配“/admin/*”这样的）全部都走到基于main.jsp聚合的逻辑中去了，通用的部分全部在main.jsp中完成，变化的页面依然根据原有的View Routing的映射来寻找页面，聚合这件事情，就真正对后续开发的程序员透明了。
对于框架来说，还有进一步解耦的需求吗？有。比如可配置的拦截 器，对于不同的请求能够使用配置为不同数量和不同个数拦截器的“拦截器栈”来响应，既可能有前置处理，也可能有后置处理。拦截器把原本在许多业务里都要重 复做的事情（比如权限校验）通过AOP这种形式横向切一刀给做了。再比如序列化，如果要返回页面，形式可能是text/html的，而要传递对象，形式可 能就是application/json这样的，将页面或者对象转换成html或者JSON响应的活儿，程序员当然也不想干……
纵观上面介绍的这些MVC框架在解耦和映射方面做的贡献，我们很容易看到，在不断地解耦过程中，层数、模块数不断在增加，复杂性应该说也在增加，配置当然更复杂，可是爱偷懒的程序总有办法让复杂变得简单。这个因解耦引起层与层之间映射的配置便是如此：
程序员自己实现；
框架实现，但是需要手动配置；
规约优于配置。
正是程序员对于懒惰的追求，造就了一个又一个好用的MVC框架，现在开发一个网站对于十多年前来说，实在是简便太多太多了，在今天谈论的角度上，未来MVC框架还会有怎样的发展趋势呢？还有哪一些通用的部分会被解耦出来，你又怎么看？
