（摘自《Expert One-on-OneJ2EE Development without EJB》第13章 Alternative Approaches to Web MVC）
虽然当前流行的是基于请求驱动的Web MVC框架，但在J2EE中还有两种比较重要的替代开发方法：Portlets和基于事件驱动的Web MVC框架。
1、Portals和Portlets
（1）概述
l Web Portal由多个完全不相关的部分组成的单个HTML页面实现，每个部分由controller-view组件实现
l Portal容器是由工作流控制的
l controller-view组件在Portal中称为Portlet
l 每个Portlet是一个自交互的组件，而不是一个工作流控制的下级代表
l Portlet就像MVC的控制器一样，接收表示请求，检查请求参数，创建数据模型，转向显示视图
（2）JSR168
l JSR168是Java的Portlet规范，定义了类似于Servlet的API和环境：javax.portlet.Portlet
l 不同于Servlet，Portlet不是一个响应HTTP请求处理的组件，而是通过Portal容器的工作流处理器获得通知，响应各种命令的回调组件：
Ø doView(RenderRequest, RenderResponse)：显示Portlet缺省视图
Ø doEdit(RenderRequest, RenderResponse)：显示Portlet编辑视图（如果支持的话）
Ø doHelp(RenderRequest, RenderResponse)：显示Portlet帮助视图（如果支持的话）
Ø processAction(ActionRequest, ActionResponse)：在Portlet提交请求给自己时，由容器调用（对于任何视图模式）
l 在一个典型的JSR168 Portlet中，doView充当组件控制器，准备数据模型，可能访问中间层资源和服务，转向到作为Portlet视图的JSP
l 自迁移的表单提交，使用标准的HTML <form>标记，使用Portlet的<portlet:actionURL>标记指定其action属性，Portlet容器会使用提交的参数来调用processAction，通过返回视图模式来调用doView、doEdit或doHelp
（3）部署Portlet
l Portlet集合以标准的WAR文件部署，只是Portlet的定义在/WEB-INF/portlet.xml中，而不是使用web.xml
（4）共享
l Portlet规范定义了它自己的MVC机制，来适应自包含Portlet的需求
l 如果Portlet容器在J2EE服务器中运行，Portlet可以通过JNDI来访问中间层的资源和服务
l 但是，Portlet看上去不可能向Web应用程序的其它组件共享本地资源，因为它们位于独立的环境
2、事件驱动的Web MVC框架
（1）概述
l 事件驱动框架的目标是应用桌面UI编程到Web环境
l 它们不把焦点集中在表单提交到依次映射到控制器进行请求处理的URL，而是把表单组件关联到由事件调用的监听器
l 它们通常不把焦点集中呈现给定模型对象的嵌入式视图技术，而是将Web页面作为保持状态和知道任何应用不同的皮肤呈现自己的组件集合
l 象Echo和WingS这样的框架，提供接近Swing的编程模型，由UI组件类生成实际的HTML代码，这使得Web设计者不容易进行定制，限制了定制HTML和JavaScript的灵活集成，而且会生成出大量不需要的会话状态
l 其它框架象Typestry和JSF（JSR127）结合了模板方法和事件处理机制：HTML布局在模板（如JSP和Velocity）中定义，实际的工作流和视图呈现由处理页面中表单组件事件的框架控制器管理
l 后来的基于模板的方法在一定程度上受到微软的ASP.NET，象JSF在很多方面就像是Java世界中的ASP.NET
（2）Typestry
l Typestry将焦点集中在完全分离的Java代码和HTML模板，将每个页面分成3个部分：
Ø HTML模板：纯HTML标记，包含由jwcid属性标记的动态部分
Ø 页面规范：定义页面实现类和页面中使用的组件
Ø 页面类：定义模型和页面的监听器
l 每个页面由任意数量和嵌套的组件组成，每个组件同样被分成类似的3个部分：
Ø HTML模板：用于组件的纯HTML标记，包含由jwcid属性标记的动态部分
Ø 页面规范：定义组件实现类和使用的嵌套组件
Ø 页面类：定义模型和组件的监听器
l Typestry的HTML模板不包含脚本和自定义标记，而是由jwcid（Java Web组件ID）属性标识的特定标记，典型的标记是<span jwcid=”…”>，在运行期，这些标记会被Typestry组件生成的HTML代码替代
l Typestry的HTML模板可以在浏览器和HTML编辑器中显示，非标准的jwcid属性标记会被忽略
l Typestry的HTML模板和JSP或Velocity使用标记代码、动态表达式和控制流逻辑实现的动态视图不同，是静态模板，需要使用页面规范合成来产生实际的动态视图
l Typestry会处理所以的工作流管理，而不需要接触HttpServletRequest 或 HttpServletResponse
l 表单提交的数据绑定到页面或组件实例的属性（Model），控制逻辑由页面或组件类的监听器实现，执行某个动作或转到不同页面（Controller）
l Typestry的页面实例是pooled；页面属性如果需要对相同用户在不同页面之间保持状态，可以标记为持久，Typestry会将页面属性保存到HttpSession中
l Typestry应用程序需要一个应用程序规范来定义有效的页面，也决定被使用的引擎类
l 引擎类是服务器端的状态管理器，通常保存在HttpSession中保持两种类型的应用程序特定状态对象：
Ø Visit对象：包含当前访问用户关联的所有状态，对应于HttpSession属性
Ø Global对象：为应用程序的所有引擎实例共享，对应于ServletContext属性
l 和页面一样，引擎实例是pooled
（3）JSF
l JSF将焦点集中在使用JSP标记库创建表单，在JSP代码中嵌入验证器和导航规则的引用
l 验证器、导航规则和被管理Bean（如表单对象）在faces-config.xml中定义
l JSF视图通过FacesServlet被调用（View）
l Action由命令风格的事件监听器实现，被调用后返回字符串结果，通常是转向视图的导航规则引用，可以通过FacesContext访问它们的环境中的对象（Controller）
l 表单对象是简单的JavaBean（Model）
l 组件由自定义标记实现，可以通过不同的插件式呈现器改变皮肤，这就允许重用相同的JSF视图到不同的目标格式，如HTML和WML（视图无关模型）
3、各种Java/J2EE方案的选择
l ASP风格的脚本编程：纯JSP
l CGI风格的请求处理：Servlet，主要是二进制内容
l 基于Servlet/JSP的自定义MVC方案：简单工作流
l 使用JSP的请求驱动Web MVC框架：Struts、WebWork等（很多选择）
l 使用Velocity、Freemarker等模板引擎的请求驱动Web MVC框架
l 使用XSLT、XMLC等XML技术的请求驱动Web MVC框架
l Swing风格呈现GUI组件：Echo、WingS
l 基于页面规范的GUI创建：Typestry
l ASP.NET风格的GUI创建：JSF
