Simple Thinking

突然想到的。

按照现在Page-Bean-Filter的编程模式，是否是JSF的方向？看别人做的JSF项目，似乎对BackBean用得非常多，而且跟组件绑定得很多。而不仅仅是把BackBean作为一个数据存放的地方。Filter似乎也只是在权限管理的时候用。

现在我的做法，是不是还是以前JSP/JavaBean/Servlet的延续，而没有体会到JSF的精髓？似乎有这个嫌疑。页面上由codelet、Html变成了JSF、html，Servlet变成了Filter，以前的request.setAttribute/getAttribute变成了JSF的Context。

JSF所代表的方向，是不是应该朝着定制页面组件的方向前进？

但是又感觉不应该是这样，因为一直强调页面和逻辑的真正分开。如果将页面各个组件定制后台支持Bean，把组件和逻辑放到一起，这样的后果会是逻辑分散在各个页面组件Bean里面。这样反而不好。

我想象中理想的MVC实现模式应该是一种数据、逻辑、页面彼此分开，靠接口进行联系的方式，绝不应该把逻辑分散到具体的数据或者组件中去，但是对于那些完全属于组件或者数据自己的操作例外。比如一个表单的CRUD操作，应该放在表单Bean中，由它自己去控制CRUD。

现在的实现方式是将Bean完全作为一个数据存放、自身操作的一个组件，页面主要负责显示，而不会参与具体数据业务处理，Filter用来在总体上控制页面数据的初始化和后续处理。

JSF在页面上强调去掉codelet的本意应该是要让页面规范化，用统一的XML格式体现，而特殊的标签由XML元数据去定义（对于JSF而言，就是Tag）；JSF的Context则是对过去JavaBean的统一管理，同样有Session、Application、Request和None（即时）的定义，相当于过去的session.setAttribute/request.setAttribute等等。而JSF页面的生命周期，感觉上像是对JSP的View开源项目的一个总结整理，对表单自动绑定、EL的采用进行了标准化，并且纳入JSP/JSF Spec。这也是Sun的一贯做法，从开源项目中吸取营养，不断更新升级Java Spec，嘿嘿，甚至可以看到Hibernate纳入Java ORM Spec的一天，当然或许改名叫EJB X了^_^。

所以这样看起来，思路并没有错，按照JSP/Servlet的思想去编程，是因为本身页面的流程就是固定统一的，JSF对前任做的修改，是标准化和扩展，而不是颠覆性的思路。其实根本上来说，JSF只是页面的一种规范和实现，它不能代表整个View层的思路。

刚做完分页，只是一种尝试。AOP侵入遇到些问题。看了一些别人分页的实现，我可不想对每个需要分页的地方都去写分页查询的实现，然后跟dataTable绑定。我要的是不管什么样的查询，只要需要分页，就能够拿到特定查询分页后的结果，然后不做类型转换直接放到dataTable中去。也就是说，分页不分页，在view层就能控制，而不用去触碰到业务层和数据层。这样对整个框架的污染是最小的。

但是现在仍然有几个问题存在：

1.一个Request/Response里面只允许存在一个分页查询。

2.分页的实现形式仍然不优雅，还没有抽象出统一的方法。

3.在dataTable的属性改变是仍然会有些问题。

4.似乎翻页的时候数据库查询多了一次，还没来得及查找问题。

现在整个页面的跳转流程都打算用jsp/faces来做，就是说在程序中，页面的跳转，都是从一个jsp跳到另一个jsp，而不会再出现servlet/action。这样的好处在于流程比较清晰，业务层对页面的侵入，都隐藏在了中间的Filter里面。只要页面上容错的机制做得比较完善，设计页面和实现页面的流程表现不会有差别。这样的结构，在新作一个项目时，只要给出静态的页面，实现起来就比较透明化了，实现的结果和文件流都不会跟设计时有变化。