jsplet:对Model 2模式的批判

哦 ! 抱歉没有认真看 你的jsplet确实是一个比较完整的框架 不是model1

你是用jsp来实现了自己的mvc 不容易. 但我不认为这是一个好的实现 

1 session过度使用是不好的
2 jsp对资源的占用比较大
3 jsp并不方便 编辑java文件还是比编辑jsp文件容易 工具也更丰富.
4 没有model1简易(jstl+javabean)  没有struts的"优雅" 定位模糊.

其实我也不喜欢struts 有时间大家一起研究研究cocoon吧
它是用管道来工作 流程控制比较随意 view超级灵活强大

thisObj只是允许使用session,是否使用session可以自行决定，这是一种使能技术，而没有object支持，结果是无法有效的使用。另外，请仔细看清楚，objectScope是一种非常精细的资源使用控制手段。

在jsplet最初的版本中，action只能写在java文件中。稍后改为可以写在jsp中也可以写在java中，请仔细看清楚介绍。


jsplet是以非常精炼的方式实现对象化。再说一次，不要把jsplet的定位向那些开源框架上靠。jsplet的开发时间大概与那些开源框架同时进行的。仔细看看设计中的可扩展性。xwork的所有特性jsplet都可以实现，而且jsplet多提供的部分就是对象化。


如果你没有理解这句话，没有理解对象化，那么jsplet的设计你就不大能够明白了。


cocoon是一个先锋概念，它主要是探索了xml框架下的执行能力。但是我们的tpl技术要更加强大。流程控制？想想事件驱动是怎么出现的。

请问什么  “可视化分析工具” 可以做到这一点  ？？？？？？？？？？？

这个时候，role_list.jsp  和 user_list.jsp里面都有一个 thisObj。而且这两个thisObj的scope都是 sesession ?

注意所有的对象模型都需要状态保持机制，所以thisObj确实被保持在session中。在webwork2中如果希望在多个action之间协调，则必须将某个对象保留在session中，否则就是采用无状态模型，所有的状态数据都持久化在数据库中，每次输出的页面都和某个action产生绑定（一种行为相关），则根本无法实现上述例子中的分解过程，因为在action模型中状态与行为无法抽象到一起并重用！ 当页面显示逻辑比较复杂的情况下，页面本身也有一些临时状态需要保持，MVC并不是意味着所有的状态都是需要持久化到数据库中的关键业务数据。在每个层次上都可能需要保持状态，MVC只是说某些状态变量更加重要，可以驱动其它层次而已。
    另外说thisObj的scope是session也是不准确的。首先注意到jsplet通过对象化实现了将状态和行为抽象到一起，此后程序就拥有了对这个整体的控制权，在jsplet中存在着对象的生命周期控制，对象的scope是自定义的，对象的生命周期是session的子部分，而不是整个session生命周期范围内都存在。请注意一下这种控制策略带来的可扩展性。我们拥有了对象生命周期的控制权，依然可以采用无状态设计，但在需要保持状态的时候，可以做到。而在webwork这样的action模型中是没有这种选择权的。

可以使用 并不意味着必须使用，所有无状态设计都可以一样应用。jsplet是一种事件驱动设计，在这一点上，更像是Tapestry或者JSF。基于actioin的设计是真正的无能使用session，它不敢应用session的原因是它对session没有控制力。而在jsplet中对session的使用控制是很自然的：当你需要对象的时候，当你需要这个状态的时候，它才存在。它出现是因为需要它存在。在面向action的框架中，你仍然需要解决状态问题。只是框架无法提供支撑，自己解决而已。
我想，大概大多数人开发的程序都是CURD的堆砌，所以很难理解一个复杂的应用中的状态管理的必要性。有了对象支持之后，才构成整个框架的概念上的完备性。


TCP是有状态的，而且其状态机还很有名。

觉得状态支持不好，那是因为对象不好吗，还是都是函数调用最快。

另外不要把设计理念和性能混为一谈。设计体现的是对概念的把握，能够达到合适的抽象，而性能是实际实现过程中的限制。在概念能够支持的情况下，可以采用技术手段解决性能问题，或者退化到较低的层次，这是一种选择权。而概念无法支持的情况下，就需要各种穿墙打洞的方法来实现。

thisObj重要的是概念，如果需要，它可以把状态序列化到cookie或者dotNet那种参数中，这只是个实现问题。

通过楼主给出的例子、架构图、和进行的讨论，能够大致看出来，JSPLet的入口view.jsp ，其实是起着 Dispatch Servlet的作用。这个view.jsp负责调用 action.  这也正是其他MVC框架中Dispatch Servlet的作用。（web engine -> web action -> web object -> java bean）
从架构图中，可以看出，其他MVC框架中的view部分，在JSPLet中是用HTML Template实现的。
同样，其他MVC框架的Dispatch Servlet负责最后的Response输出，Action只负责提供Model and View name。JSPLet的 view.jsp也是负责最后 Respone输出。

其他MVC框架中的入口 Dispatch Servlet 一般只有一个，它下面的URL Dispatch Map 站点地图，确实都要集中配置在这个Dispatch Servlet下面。
JSPLet利用 jsp的 Web Server自动定位优势，相当于提供了多个Dispatch Servlet。这个方面确实具有优势，为用户提供了更高层次的更丰富的控制。其他MVC框架还做不到这一点。

WebWork的方法是把Action降低一级为Model，让ActionInterceptor接手以前Action的工作。
我采用的方法，是把Action直接提高一级，由Action直接控制response输出。
但无论怎么做，只要入口是Action，就确实达不到JSPLet的程度。一定要事先定义并配置好一个 Dispatch Servlet，然后再配置下面的Action。

我的一个弥补想法（还是在传统MVC框架基础上），是简化URL -> Action Class的Dispatch过程，力图做到少配置，或者免配置。
这样Action的增加，不需要修改Action Config, 只要URL Pattern 和 Action Class Name 之间符合一定的Pattern。也是力图达到灵活，当然达不到JSPLet的灵活程度。

我觉得，
1.  User Defined Dispatch Servlet  (view.jsp)
2.  URL Parameters -> Listener method, scope 的binding

是JSPLet的相当优秀、前锋的特性。非常值得借鉴。

----

我主要 对JSP作为主控程序 持保留意见，虽然可即时修改编译是很好的特性，但出于性能考虑，JSP终究要编译为Servlet。一个应用中的 Dispatch Servlet太多，Web Server的负担就要加重。
其他的MVC框架中，JSP一般作为view使用，还可以用其他的template技术替换掉，比如，freemarker, velocity。
但在JSPLet中，JSP是作为主控程序，是无法替换的。

这个方向上，我再仔细考虑一下。
JSPLet主要是利用了Web Server的自动 JSP dispatch功能实现了这种 User Define Dispatch Servlet 的灵活性。
我想，能不能找到一种方法，能够进一步提高Action的位置，和灵活性，而又不需要引入 Servlet 的负担。
前面的“简化URL -> Action Class的Dispatch过程”思路，还不够彻底。只是一种权宜之计。

听起来很美的特性。

Action Centric 框架，确实需要自己解决 Session中保持状态的问题。

Tapestry或者JSF大致做到了 Page Component 的 HTML Part 和 Listner Code Part 的状态绑定问题，但是由于自动生成的 Link 中包括了框架本身需要的状态，付出了 Stale Link等代价。

看到JSPLet的介绍，URL Parameters 是自定义的，还是比较干净的。而且有专门一种方式指定 Listner Object 的 Scope。应该不存在 Stale Link 的问题。似乎更优越一些。

楼主对于状态，对象化的描述


虽然，楼主对 JSPLet 的宣传描述说，JSPLet 能够流畅的管理Action Object 的状态，和生命周期。
但我不相信，JSPLet 能够完善的做到这一点。这是由 HTTP 的 request - response cycle 之间无联系的本质决定的。

也许“所有的扩展都直接体现在url格式的细化上”的言下之意是：


我感觉，JSPLet只是为用户多提供了一种Object Scope定义方式（URL Parameter扩展）而已。如果用户需要保持状态，还是要自己清楚地要求和定义Session Scope。
JSPLet也只是根据用户的这种指定，被动地管理Object的生命周期。

楼主说，Object 的生命周期 只是 Session 声明周期的一个子集，那么请问，Session有效的时候，JSPLet什么情况下会主动清除 Session 中的 Object？ 如何判断 用户不再需要调用这个 Object了 ？

首先说明一点，我无意宣传jsplet框架的使用，因为jsplet并不开源，这里仅仅是以jsplet的设计为例讨论一些设计原理而已。
关于object生命周期的管理以及使用拉模式，如果套用现在流行的设计术语，那就是涉及到所谓的IoC设计（控制反转)


IoC的Container现在很受追捧, 但真正的IoC设计思想并没有引起大家的重视。也许大多数人使用的都是成品吧，以至于把成品的功能等价于其所依赖的设计原理。Spring等所建立的IoC更准确的说法是Dependency Injection，只是IoC的一种体现。其基本思想是一个对象并不控制所有与它相关的部分，而是把控制权交给使用对象的人。这里重要的就是控制流（信息流）的反转。
对象生命周期的管理也是这样，并不是由一个Manager猜测用户是否使用该对象，而是由用户直接标明他的态度，直接发出指令。
参考一下桌面应用中的资源控制手段，我们打开一个窗口，与系统进行交互，此时占用资源，关闭窗口，则该窗口以及其子窗口所占用的资源都释放。在jsplet中对象控制策略类似。当用户从某个功能区退出的时候，即当用户访问其它scope中对象而放弃当前objectScope的时候，开始做资源清理工作。即用户的行为和意向直接驱动着系统的对象管理层。当然，如果用户一直不发出调用，那么系统只能猜测用户的行为，用户是否已断线或者正在思考？在这种情况下，如果控制资源，则需要通过AOP给thisObj 加上类似EJB的功能。

这里所要描述的不是一种巧妙的trick，而是一种设计上的必然。现在大家言必称OO，可OO到底意味着什么，除了书本上的话语，你能不能用自己的话描述一下，能否体会到那种必然。OO如果是一个有效的概念，它在软件以外的领域是否有着对应。按照早期教科书的说法,OO是为了模拟现实世界，这种说法只是反映了设计上的一种困境，一种思想上的贫乏。面向对象最直接的意义在于标示了状态与行为之间的耦合，此后在程序中可以用一种显式的，一致的方式来操纵这个集合体。在界面上，我们看到一个组件，在模型层，我们看到的还是那个对象，在配置文件里我们还能清晰的辨别出它来。可在webwork这种面向action的框架中，package看起来像对象，在action层却不见了，当我们需要同时使用两个action的功能的时候（如同时列出role和user)，以前的action不能用了，只能再写一个。想一想，我们最少需要多少概念，最少需要做多少工作，才能在软件中建立一个合适的概念框架，怎样才能保持这种框架中的张力。