struts2源码——XWork设计原理(二)

本文探讨了MVC模型中的数据流与控制流概念,重点介绍了Model层作为数据载体的不同形式,包括Map、FormBean及POJO,并讨论了它们各自的优缺点。此外,还分析了控制层如何处理业务逻辑。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

数据流与控制流

MVC模型中的Model层,其本质是“数据”,正是数据在不同层次流转,才使mvc真正融合起来。

Controller是MVC的核心控制器,负责请求数据的接收,负责业务逻辑的处理,负责响应数据的收集,负责响应流程的控制,当数据流融入控制层之后形成逻辑处理和程序跳转的结果就是控制流。

数据流的载体:

(1)Map

Map是一个键值对,Servlet标准在设计HttpServletRequest规范时使用了类似Map结构来进行数据交互。

使用Map的缺点:

1.Map作为一个原始的容器数据结构,弱化了java作为一个强类型语言的功能。

2.使用Map的Key作为数据存取的依据,使得程序的可读性降低。

3.是Map结构进行数据交互,无法实现必要的类型转化。(Map无法提供java所具备的强类型语言的基本功能,这些类型转化需要应用程序自行处理)

虽然Map有这么多缺点,但是它却是最具备灵活度的一种数据结构,因为Map对数据格式,大小,数量都没有特殊规定,使得成为最具扩展性的数据载体。

(2)FormBean

FormBean是Map的升级版,是一个强类型的数据结构,在Struts1.x中被设计成MVC中的M部分,承担着数据载体的重任。

存在的问题:

1.FormBean被强制继承ActionForm。

2.FromBean被强制与框架的功能耦合在一起。

3.FormBean在参数复杂的情况下,几乎无法工作。

为后来纯POJO的出现奠定了基础。

(3)POJO

1.作为JavaBean,POJO是一个具备语义的强类型,不仅可以享受编译器的类型检查,还可以自由定义我们所需要表达的语义。

2.POJO不依赖任何框架可以在程序任何一个层次被复用。

3.POJO突破了FormBean对于页面元素唯一对应的限制,我们可以将一个页面中的元素自由映射到多个POJO中去。

控制层:

它的核心职责是处理业务逻辑,而其他的辅助逻辑则由框架帮忙完成。

事件处理流程的规范化:

1.划分事件处理流程步骤。(对事件处理流程中的不同处理职责进行语义抽象,从而将类似的流程步骤归为一类)

2.定义事件处理节点对象。例如:Interceptor,Action,Result等。

3.组织事件处理节点对象的执行次序。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值