xwork设计原理

XWork 是一个灵活而可靠的基于命令模式的开发框架

 

人人沟通

沟通协议   发起方    沟通内容   相应方

 

沟通协议是沟通内容的基础   沟通内容是沟通协议的具体表现形式

发起方和响应方的角色并不固定，只有在一个交互回合中才能确定角色

 

人机沟通

沟通协议 请求内容  响应内容

请求和响应不断的家伙过程 构成了bs体系结构的应用构架的基础

对应的java的三种模式

参数--返回值  param--return  模式

 

参数--参数    param-param模式

  将请求和响应同时置于参数位置的模式

 

 pojo模式

   进行请求响应的处理类自身是否一个有状态的对象

 

 

这三种模式分歧是 不同的实现方式使用不同的编程元素来表达请求-响应模式中不同的逻辑语义

原因  主观  不同的实现模式 他们考虑问题的出发点不同

客观上  不同的编程元素所能表达的逻辑功能存在着天然的差异

 

总之  对于编程元素作用的理解不同，直接导致了不同请求-响应模式之间的差异

 

虽然他们不同但都是在使用java语言语法元素来和整个请求-响应模式的过程中的元素进行配对

 

请求内容 请求的数据

请求处理载体  进行逻辑处理的场所

响应内容  逻辑处理的结果数据

响应跳转处理  逻辑处理完成后的程序流转方式

 

数据流实际上表现为数据内容，其核心包括数据请求和数据响应，而控制流实际上表现为方法进行逻辑处理的过程，包含程序执行方向  

数据流和控制流是两股隐藏于程序内部的神秘力量，是程序运行的核心驱动力

 

真正贯 穿mvc框架并且将mvc的各个模块粘合在一起的是数据，数据作为粘合剂，构成了模块和模块间的互动载体，把mvc真正融合在了一起

 

控制层负责请求数据的接受

控制层负责业务逻辑的处理

控制层负责响应数据的收集

控制层负责响应流程的控制

 

控制流实际上是数据流融入控制层之后形成的逻辑处理和程序跳转的结果

 

 

数据载体

 使用map作为数据载体

       map作为一个原始的容器数据结构，弱化了java作为一个强类型语言的功能

      使用map中的键值key做为数据存取的依据，使程序的可读性大大降低

     使用map结构进行数据交互，无法实现必要的类型转化

使用formbean作为数据载体

     formbean被强制继承actionFrom

     FormBean被强制与框架的功能耦合在一起

     FormBean在参数传递非常复杂的情况下，几乎无法工作

 

使用pojo作为数据载体