[]
Martin.guo
J2ee
架构中一般都要考虑
Web Framework
的选择。很多人选择比较流行的
Struts
。项目组中遇到过这样的情况，有些人不熟悉
Struts
，而有些人又对
Struts
青睐有加。有没有一个折中的办法来满足所有的人呢？
我是这样设计的：
通过拦截提交到
ActionServlet
上的
http
请求，经过
Http Parse
来收集请求参数，以
Name-Value
的形式存放为请求值对象，并且放在请求线程相关的上下文中。这个时候你就可以在
Action
执行结束前的任何地方拿到这些请求数据了。
在这个基础上，我们保留了
Struts
的
Action
，并且规定
Action
的
execute
方法里不能出现任何跟业务相关的代码
,
仅仅是负责页面的流转。
那么业务怎么办呢？我们定义了一个接口
Command,
它也只有一个方法
,
我们也取名字为
execute,
并且没有任何参数和返回数值。该方法的职责就是执行业务逻辑。这个时候你就要问了。
Action
里抽离业务逻辑，怎么调用
Command
呢？请求提交的数据怎么给
Command
呢
?Command
执行完后的业务数据怎么返回？
我们设计了一个业务执行器，它的功能就是执行
Command
的业务逻辑实现
.
而把执行器的执行写到了
Action
里面。这样就隔离了页面流转和业务执行。
Action
的代码显的很简练和模板化。
由于请求数据是放在请求线程相关的上下文中，所以可以很方便的拿到。同时
Command
执行完毕的返回数据也是通过这个上下文返回给
Action
或者其他跟此请求线程相关的组件，说白一点就是此线程能够跑到的任何代码处都可以去跟上下文交互，存取线程相关的数据和服务。
设计到此为止，已经可以回答开头的问题了。
对于熟悉
Struts
的人呢，可以积极放心的使用
Struts
标签，使用
Formbean,
但有一点就是自己要把
FormBean
放到线程相关的上下文中，这样你就可以在
Command
里面去拿出来工作了，同时
Command
执行完毕后，你就可以顺手把返回数据填充到这个
FormBean
里面去了。跟你平时使用没有太大区别。
而对于不熟悉的人呢，你可能不喜欢写
Struts
标签，也可能不喜欢死板的
Formbean,
那么
OK
，你完全不用关心这些，你只要直接在
Command
里面去写逻辑代码就可以了。但有一点就是要，你要手工把返回的数据集合放到
request
里面去，然后到流转的
JSP
里面取出来展示。
OK
，皆大欢喜。
msn:gdq123@hotmail.com
软件架构是软件系统一个高层次的结构体现，显示了系统分解后组件的布局和组件之间的关系。好的架构描述应该包含架构的多个视角，组件的设计和扩展描述，以及为满足功能性需求和非功能性需求的设计原则。
一般说，软件架构分为5个步骤，
1.建立架构的任务并且形成架构团队。
2.建立并且文档化架构需求。
3.设计架构
4.验证架构是否达到需求
5.发布架构到开发团队
然后我们细说这五步骤
第一，架构是需要有目标的，一般是为了满足长期的业务需求。然后去制定任务并且明确里程碑。让架构组的每个人都明确架构的目标以及任务的进行和任务之间的关系。总体架构设想这个时候需要出来了。关键组件设想也应该有了。
第二，这个时候就需要按照目标去分开整理架构的需求了。开始可能是很多的需求索引，每个索引就是一两句话的表达。对于索引要给出简单的描述。索引评审之后需要细化需求，是一个更为详细的需求整理，除了文字描述，还可以配置图形等。然后要做的就是建立use case去覆盖这些需求。
第三，设计架构可以分为概要设计和详细设计阶段。概要设计需要给出一个比较轮廓性的设计说明，能够比较简要的通过这些设计元素去阐述use case，在总体上把故事讲完整。然后评审，进入详细设计阶段，细化的设计更为完整和贴近实现。同样需要一个说故事的过程，把use case通过详细设计的元素说的更为生动和形象。然后去实现和整合。
第四，验证的过程是测试的一个过程，在需求阶段会确立很多测试计划和用例。对需求进行一个扫荡，看实现是否到达了承诺。
第五，不断测试并且反馈修改之后，稳定版本就可以发布到开发团队了。
个人观点，请大家多讨论。
架构的设计部分
1。更应该侧重组建的分解以及组件之间的接口关系。比一般的软件设计过程，更突出组件的接口特性和使用描述。组件的功能列表，生命周期，并发情况说明，通讯消息格式等。
2。架构中的组件是有统一的架构思想和原则。组件是要被约束的。
3。组件需要提供事例代码，典型应用场景，异常以及测试说明。
4。组件有时候是要映射到物理视图中的进程。
5。侧重架构系统的动态特性，组件之间的协作关系。
msn:gdq123@hotmail.com