从级列理论看MVC架构

cocoon的文档中有这样一段话：
Traditional Web applications try to model the control flow of a Web application by modeling the application as a finite state machine (FSM). In this model, the Web application is composed of multiple states, but the application can be only in one state at a time. Any request received by the application transitions it into a different state. During such a transition, the application may perform various side-effects, such as updating objects either in memory or in a database. Another important side-effect of such a transition is that a Web page is sent back to the client browser.

    Servlet模型提供的正是一个最基本的基于IO的FSM模型：应用程序的状态变量存储在session中，应用程序根据用户请求更新session中变量的值。这里一个隐含的假设是session中的变量是不相关的，因为servlet模型中没有提供任何机制来同时操纵一组相关变量，例如我们在session中存放了三个变量name, title, data, 如果我们希望删除这三个变量，我们必须通过三次独立的函数调用来完成，servlet模型本身并不知道这三者之间的关联关系。
    当web应用程序逐渐变的复杂起来，这个最简单的FSM模型就显得力不从心了。因此发展出了MVC模型(Model-View-Controller)，这是对有限状态机的一个精细化。首先我们识别出session,request中的变量之间存在相关性，而且变量之间的地位也是不平等的，某些变量的改变将直接导致另外一些变量的改变。因此变量根据相关性被聚合起来，构成很多对象。应用程序的状态不再由一个个独立的变量构成，而是由具有更丰富语义的对象构成。在大的结构方面，一些基本的对象被分离出来，构成一个核心,即model层, 而外围的变量被分割在不同的view中。 在流行的struts和webwork等MVC框架中，变量的聚合都定义在action层， 各个相关的action并没有汇聚成一个具有独立意义的对象，似乎仅仅做到了model层和view层的分离，在model层内部并没有建立合适的模型，即struts和webwork等建立的MVC模型中隐含假定整个model层内部是没有结构的（注，我对struts和webwork的了解限于简单介绍文档，这里的说法可能并不准确)。一些更加精细的MVC架构直接支持model层的分解，即model层由一系列不相关的对象构成，每个对象具有从属于自己的action。沿着这个复杂性发展的级列继续下去，我们可以知道，当对象之间的交互变得更加复杂的时候，我们需要框架本身能够直接支持model层对象之间的相关性。最简单的控制关系是树形结构，即父节点控制子节点，父节点销毁的时候子节点自动销毁。这样就构成所谓的HMVC(Hierarachical MVC)模型。在这个模型中，model层由一系列的对象组成，而且这些对象被分割到不同的package中，组成一个树形结构.