[WebWork]学习笔记之（一） - [Java/J2EE]

[WebWork]学习笔记之（一）

1.关于MVC

    MVC(Model-View-Controller)模式最初由SmallTalk社区开发，以解决GUI应用程序中三个部分之间的交互，降低之间的耦合度，让每一部分都专注于自己职责，而无需担心其他部分。随着开发者不断的改进Web开发技术，MVC的核心概念也在Web开发中得到了延续。MVC模式设法减少可复用的域模型（Domain Model）与显示代码之间的联系，通过在显示层和域模型之间引入控制器（Controller）来实现这点。MVC框架已经占据了Web开发的统治地位，WebWork,Struts,Tapestry,JSF等都属于MVC框架。

1.1 经典MVC模式

     经典MVC中的事件流如下图所示：

 

 

 

 

 

 

 

 

用户与视图（View）进行交互，控制器接受来自视图的事件并对模型进行操作，根据用户提供的数据更新模型。视图收到“模型改变”的事件通知，将模型更新的结果通过视图传回给用户。这种模式在单机且实时更新的应用程序中可以起到很好的作用。但是在web开发中这种方式并不可行。

1.2 经典MVC模式的更新：前端控制器（Front Controller)

   在Web版本的MVC中，视图（即浏览器）是不能直接调用控制器的，视图不是一个可以被更新的对象，但是可以基于Web请求映射成不同的URL，客户在发送一个新请求的时候随之呈现一个相应的Web页面。在Web应用开发中经典MVC模式通过使用前端控制器模式来实现。如下图所示：

这个模式包含了一个分发器（在Java的Web MVC实现，通过Servlet来实现分发器），分发器将请求URL映射至需要被执行的命令实例（Command Instance），命令实例在WebWork或者Struts中就是Action。Action与系统后端的服务进行交互，通常这些服务会组合在一起作为模型。命令实例在处理完业务逻辑之后返回一个标识代码，标识码会映射到某一个视图（通常为一个Web模板页面）。最后，结合控制器和模型，将视图呈现给客户。

1.3 MVC演化：页面控制器（Page Controller）

    另外一种MVC模式也通过一些框架实现并流行起来，譬如Microsoft的AASP.NET。在这种MVC模式中，并不是分发器去寻找一个控制器并执行，而是直接到达视图并且在继续生成视图之前调用相应的控制器。虽然这种模式丢掉了许多经典MVC实现中所使用的某些解耦合特性，但可以提高开发效率并拥有强大的工具支持。

     前端控制器和页面控制器的对比

图1-3和图1-4展示了控制面板的两种实现——前端控制器实现和页面控制器实现之间的区别。由于X，Y和Z部分职责的分离，页面控制器可能看起来更加模块化，但是良好的面向对象设计也可以实现一个模块化的前端控制器。WebWork同时支持这两种实现。

2.关于框架和容器

    从根本上来说，WebWork是一个MVC框架，同时也是一个轻量级的容易。Rickard(Webwork和JBoss创始人之一）在构建最原始版本WebWork时说过：“框架的强大之处不是源自于它能让你做什么，而是它不能让你做什么。”Rickard的话解释了什么是框架：框架使混乱的东西变得结构化。而Web应用程序框架则鼓励开发人员使用一系列框架所提供的基础类和类库，从而避免杂乱的JSP说造成的混乱。

     框架通常定义了它们本身不能做什么，而另一方面，容器则在大多数情况下定义它们自己能够做什么。譬如Servlet容器，现在有很多不同的Servlet容器可供选择：Tomcat，Resin，WebLogic和WebSphere等等。容器的设计是为了装入你的代码并且为你的代码提供特有的特性。