Spring MVC两个严重的问题

Spring MVC由于纳入Spring强大的框架体系而让人感觉到无比的强大。但对表单处理流程层面还是有些问题。一些初级用户遇到的大多数问题都可以通过重载相关的方法就能解决，例如动态路由不同的视图、与Request,Session相关的验证等。我这里提出的问题主要是Spring体系框架无法解决的问题，如果我们引入自己的解决方案，将会造成大量的冗余代码和频繁地数据库访问等问题。首先我对这个问题做一描述：
在Spring MVC表单处理中基本的思路是(精简了一些)：
1、通过Http Method判断是初始化表单页面还是提交表单。如果是POST认为是提交表单，非POST认为是初始化表单输入页面。
2、非POST的过程基本是：formBackingObject->showNewForm->showForm->referenceData
3、POST的过程是：formBackingObject->bind and validate->onSubmit->showForm->referenceData

无论是POST还是非POST（最常见的是GET）在所有的过程中我们经常有两个需求：
1、整个过程中共享数据如何传递（例如在formBackingObject中为了准备对象从数据库导入的数据如何直接传递到其它各个环节）。唯一能解决的一个入口是errors.getModel，但在formBackingObject中根本没法得到，因为errors的形成是在 formBackingObject之后的。这也体现出Spring MVC在设计上的一个不合理，Model就Model为何要用Exception/Errors的方式来维护了。Spring MVC在很多地方都用errors.getModel来获得Model的传递。有些朋友可能想到在Command Object中进行自己的维护，但这种危险是显而易见的，因为Spring绑定的时候的数据来自客户端，它可能随意填充和覆盖我们维护的数据。
2、安全问题。我们解决安全无非有两种方式：从整体功能级别的能访问和不能访问和根据业务逻辑程序的检查。针对后者Spring MVC就会出现问题，例如formBacking意味着向用户显示数据，很可能需要进行权限逻辑，但往往进行权限逻辑又要进行大量的数据库操作，这和第一个问题结合起来，将会出现比较严重的频繁访问数据库问题。

这个问题就Spring2.5.2版本是有不足的，目前解决简便的解决方法没有。除非重写（变更流程不是一个框架让普通用户应该做的）一下Spring表单处理的核心流程方法。