MVC实现中控制器servlet向jsptag转变后参数维护方式的考虑

 MVC模式提供了标准的表达层和业务层逻辑分离的模块建立的原则，不过在JSP中实现MVC要面临无状态的环境，而状态维护是MVC模式实现的前题。因此，维护MVC中的状态成为实现MVC/JSP时的最大难题和成本构成因素之一，它的缺点在struts项目中显露无遗。状态维护的困难最终表现为多步控制参数维护上的困难，OPflow提供了一个试图面对流程对象进行维护的方式，但随着JSP标签的出现，令JSP MVC中的C有可能更适宜用标签实现，又进一步令整个JSP/MVC实现方式面临又一次的检讨，但也可能是一次进步。

    OPflow本质上是为了在WEB应用中实现MVC控制流而设计的。对于WEB应用中是否应该使用MVC模式，在技术社区中仍然存在很大的争议；而针对在网上兑现MVC模式的一些典型框架，象.net以及java的struts，在实际应用中都显得不尽如人意，常常是得不偿失。MVC在WEB应用中的 Module问题上基本上达到了分层按功能划分组件功能，V视图部分以脱离业务和底层逻辑的方式显视，这两点都已经没有太大的争议；焦点在于C，如何定义 C？如何在没有严格状态保留的情况下安全地使用C控制器？在MVC模式中如果控制器每个操作，象每个servlet.action.do,都只是针对一个目的对象（象一个订货记录）的一个操作，那么也就失去了MVC的实际意义.把实际处理功能放在再下一级模件中实现倒也是一个妥协的办法，不过，结竟那不是正道，因为，这里讨论的是是不可以使用MVC提供软件开发和运行的效率。所以在实际操作中都是使用一些传递的参数，象"act"告诉控制器类型，通过变更不同的参数从而进行不同的控制，以达到最大效率的代码功能重用；这不一定是最大程度的功能组合，到底重用到什么程度合适，我觉得需要的实际的工作中按项目要求进行微调。

    同样的逻辑也存在于V视图上。如果开发者希望自已的视图部分成为一个显示框架(微软的word,甚至是浏览器就是一个显示框架)，而不是每一种显示对象的每一种细节都必须是一个程序的话，也必须是根据不同的指示参数提取不同的内容，以达到最大效率的和最低成本的模块重用。这样，无论是C还是V，如果不想让自已的开发变成随机延伸的数不清的功能过分单一又过分相似的C和V，就将面对着另一个困难：处理一连串的act参数。而这些参数一般情况是放在 request.parameter中传递。在与一些版友的讨论中发现一些朋友会混淆参数所存的命名空间，我认为，session一般用于会话跟踪的参数，而不应与界面关联；而application应该是全系统的公共变量；同理，pageContext应该是仅止于当前页面；如果不明确这个命名空间，会把自已投入参数混乱的陷阱。

    由于WEB应用不存在象VC++/VB/JavaSwing那样的单一运行时状态保持环境，所以当出现多步操作而必须共享部分变量空间时，大致只有两个办法：一是在session中建立面向操作上下文（对象）的helper，二是在request过程中维持多步的状态变量一致性。前者是较通用的办法，但缺点也是明显的，就是每一种操作都要考虑一种helper,然后使用Vector,arrayList但集合类型地变量进行维护；显然，struts中的 formBean和DynaFormBean,就是这样一种helper。后者如果没有一些工具帮助的话，在多步操作中要维持变量一致性简直就是一场恶梦。而Oplfow就是这样一种工具。

    hanva.Opflow的设想是使用一个外置的xml文件，把界面的操作形式看作是一种对象，定义为flow，每一步操作对应的URL看作是flow的一个元素step，通过判断所在的step，按约定方式组织各个环境的变量，包括变量的逻辑转换，象垃圾回收站中deleted将取反之类。在它的帮助下，可以把不同的页面轻松组成一个个一步接一步自动维护的WEB功能模件。设想合理，实现后的运行也很理想，不过在运行一段时间后，仍发现有不足之处。

    其一，是xml的修改必须重启应用才能重新载入内存；其二，对于页面人员来说，"<hanva:flowlink flow="on_off_line"/>"这样的路径显得不太直观。第三；这不是OPFLOW直接的问题：在面临权限控制时，基于action的控制器不便实现与jsp同样的界面控制逻辑。后面这一条可以作进一步的解释。这是指在WEB上开放的连接，理论上是说所有人都可以同步访问的，无论它是V 还是C，只需要符合相应的条件，就可以实现操作。如果不能解决这个问题，那么WEB应用本身没有可靠性可言，但如果解决方式过分复杂，象每一个程序进行一次复杂的PMI验证，然后最后两句执行实际操作，这样WEB的性能很差，而且整个项目开发的工作量会成级数的倍增。解决这个问题的关键在于共享单一变量空间（会话helper是一种方式，不过缺点有如前述），并由一个共用的访问验证组件完成验证。由于这样的组件是复杂的，如果在一套系统上维持两套达成同样功能但机制不一的PMI组件，那么程序开发和维护成本也会成倍数增加。

    Jsp标签提供了解决这个矛盾的一个途径，并且，在此前的文章中已经提取，jsp标签可以看作是一种在jsp中行的可运行时配置变量的servlet，理论上可以由servlet实现的controler也可以由jsp标签完成，并且，它较servlet可以访问jsp上下文空间，从而能够实现与jsp访问PMI控制同样的逻辑。这是我决定把servletcontroller逐步转向标签controller的原因，尽管标签仍没有解决jsp难以维护顶级模板的缺陷。不过，这就影响到MVC中关键的C的角度，并且，实际上是把V与C使用同样的技术方式（标签）作为统一媒介加以实现了，从而也必然影响到 OPFLOW。这样一来，我的构件JSPWEB应用的整个项目基础模式就出现了变化，虽然很可能是进步，但模式的成熟总是需要一些波节，它的优点和缺点也必须在使用过程中才能真正体验出来。

    原来以为JSP控制器标签的使用会大大降低opflow的必要性，因为opflow的其中的一个目的是弥补servlet不能方便地调节运行参数而开发的;而调用控制器标签的jsp页面本身也可以作为参数调节的空间，这样opflow的必要性是不是就减低了？但实际使用时却发现对于运行时过程参数的维护，opflow还是很有必要的，除非在标签中集成原来的维护参数的底层代码，这是可能的，因为随着标签的使用，jsp数量的增加已经不意味着太大的维护量，它们实际上只是一两个标签的载体。至于如何合在一起使用才最高效，还需要在应用中慢慢总结，归纳出一套可靠高效的程序模式才算对得起自已此前的工作。

http://zwwwxy.blogchina.com/blog/article_81038.1391946.html

 从当前的情况看，操作标签是对servlet控制器的更替而不是对opflow的更替，标签本身不能简单地实现低成本的参数维护；不过，在单一步骤时，这是无意中发现的，由于ActionTag是使用了与Struts.ActionServelt同样的转向代码，我并且加进了从若为空就从header中取 referer的部分作为转向目标；这样一来，无意中就令单步操作在操作完毕后反回了同条件参数的显示页面——显然，把标签直接写在这些页面上也可以达到同样的效果。不过需要在标签生效前先用logic.prisent之类的判断一下是不是要先进行标签标定的业务操作。