[]
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
软件架构师是什么？需要什么样的知识体系？如何成为优秀的软件架构师呢？
第一个问题：
软件架构师一词应该是对应系统架构师，都是架构师，但侧重不同。在4+1视图中，我觉得如果把架构师分为这两种的话，软件架构师应该是站在逻辑视图和开发视图的角度，而系统架构师则更多的是过程视图和物理视图。当然，这两个角色就象是人的两个眼睛，缺少一个都会定位不准确，容易是系统目标偏离。
当然了，现实世界中，一般这两中角色集中在一个人身上体现出来，或者一个小组。很多公司都不设置此类职位；有的公司则分工很细。
第二个问题：
知识体系不好说，只说重点的吧。
软件架构师的职责是把需求转换为软件世界的模型。4+1视图中以use case作为核心，其中功能性需求以及部分非功能性需求会被软件架构师通过分析和设计，映射为各种软件设计模型。从OOA/OOD角度说，use case 在这个过程中是要转换为各种UML，其中类图，序列图，状态图是最常用到的。这个转换过程是需要智慧的，use case是目的，各种OO的原则是指导，设计模式是经验，灵活运用是能力。里面蕴涵了设计的美感，我觉得这个过程是衡量一个软件架构师的最重要的指标。
当然这个过程是迭代和反馈的，我觉得概要设计和详细设计只是思考同一个问题的粒度不同而已。
另外就是我们要熟悉语言，详细设计是要转换为代码的，而且跟语言是有关系的。语言比如java/c++等，详细设计的模型是有很多不同的。就需要软件架构师有过这个过程，并且是非常良好的映射。
除了语言就是要熟悉某个技术领域，比如J2EE/DOTnet.从J2ee来说，可能需要了解比如jsp/servlet/ejb/jndi/jta/jdbc等。还需要了解各种web framework,o/rmapping,ioc/aop容器等等。还有的就是一些技术组件和业务组件，不如workflow,rules engine等等。另外比如各种database.熟悉这些东西的目的，是把这些软件和组件合理并且有机的组织起来成为一个开发的架构。这个过程是需要创造力和想象力的。可能很多人认为这个地方正是软件架构师体现能力的地方。
第三个问题：
我不是很清楚，但我认为意志和想象力能够使每个有目标的人达到彼岸。
msn:gdq123@hotmail.com