如何从dwr安全性看系统分层设计？

在上一篇的文章中谈到了ajax的dwr的主要流程，现在来看看dwr在安全性上的实现，dwr自己表明很认真的对待安全问题并在通过下面的步骤防止出现安全问题
1、dwr只会对dwr.xml中定义的java bean和method进行映射create元素定义的class
2、dwr只会把convert中定义的class进行转换

dwr否认它的技术会给系统带来新的安全隐患，注意我用了“新的”这个词语，因为dwr觉得dwr存在的安全隐患是其它框架同样存在的，只是在dwr中它们更显而易见了，并表明dwr不打算在安全性上花太多的精力，不会在提高安全性上做更多的工作，它建议用户通过使用Acegi来实现用户的安全需要。

我们再来看看使用ajax会给我们的系统设计带来什么样的变化，在dwr的使用上，我们可以看到，dwr很适合那种对小数量的局部范围进行更新的操作，对提高系统的交互性有很好的作用，在页面的整合上却没有优势，这种特性几乎注定了ajax将是structs等一些框架的补充，和其它框架的关系是并行的同事存在的关系，根据我的了解，struts等框架提供了许多便利的开发特性：如validat和统一指派的特性，使不少的开发人员都习惯而struts框架也推荐了把事务和系统的安全性通过扩展structs这些框架来实现的这一做法。

扩展其它框架中实现的事务和安全性仅仅对使用struts等框架的操作有效，对dwr的操作则完成无效，我们必须对dwr重新实现它的事务和安全性，或者ajax的dwr框架确实没有增加新的安全隐患，但和struts把权限限制在action中不同，ajax对安全的要求更严格更细了，对每一个操作都提出了验证权限的安全要求，一般struts的一个action会有多个的列表或者操作结果，这是ajax为系统提供更好的交互性的必要开支。

这种独立使用一种框架时不会出现任何的问题，但在加入ajax的后就会打破系统的统一的整体性，让人觉得很尴尬的，谁也不想一个系统存在着两套的事务管理和权限控制。在ajax出现之前大家都习惯于采用一种mvc框架解决所有的问题，很少的人会想到会在系统中使用两种的框架进行互相补充的。这样我们就需要重新对系统的架构进行考虑，进行更为严格的分层管理。

一般而言控件的功能越单纯越好，系统的事务和安全性跟其它的框架和组件独立开来是一个好的习惯，很多人都觉得，更为灵活的系统架构好是好，但面对好架构所增加许多的工作量时，很多人会选择使用直接编码对应的方法，而拒绝使用明确的分层架构和接口编程，其实这是一种短视的行为。一开始就把系统的运行环境和系统的粗粒度限定在一个相当小的范围，这在后面的升级或者替换相应的框架和组件时会遇到更大的困难和工作量。