[]?
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