引用: |
如果在Action Centric的框架,要避免兩個訪問點,可以這么定義。 view.do?&templateName=a &objectName=/@Demo&objectEvent=test |
這 種做法就是程序自己處理而不是框架支持了。我說過,工作就是那么多,只是框架做什么和程序作什么的分工而已。說jsplet是page為中心也不太準確, jsplet是以對象為中心,只是指定了希望使用的視圖頁面而已。view.jsp放在前面只是jsp實現上的一個問題,
引用: |
Action Centric 確實比較麻煩,必須同時傳入角色列表 和 用戶列表的 分頁信息。 JSPLet對于這個問題是怎么處理的? |
很簡單包含兩個子頁面
list_both.jsp
<jsp:include page="role_list.jsp?objectName=/@RoleManager" />
<jsp:include page="user_list.jsp?objectName=/@UserManager"/>
在
訪問的時候通過指定eventTarget參數即可將事件路由到合適的對象,沒有響應事件的對象thisObj里的內容不變,因為前臺view顯示內容也
不變。注意這里role_list.jsp和RoleManager, UserManager對象都是獨立開發的。
引用: |
這個時候,role_list.jsp 和 user_list.jsp里面都有一個 thisObj。而且這兩個thisObj的scope都是 sesession ? |
注
意所有的對象模型都需要狀態保持機制,所以thisObj確實被保持在session中。在webwork2中如果希望在多個action之間協調,則必
須將某個對象保留在session中,否則就是采用無狀態模型,所有的狀態數據都持久化在數據庫中,每次輸出的頁面都和某個action產生綁定(一種行
為相關),則根本無法實現上述例子中的分解過程,因為在action模型中狀態與行為無法抽象到一起并重用!
當頁面顯示邏輯比較復雜的情況下,頁面本身也有一些臨時狀態需要保持,MVC并不是意味著所有的狀態都是需要持久化到數據庫中的關鍵業務數據。在每個層次
上都可能需要保持狀態,MVC只是說某些狀態變量更加重要,可以驅動其它層次而已。
另外說thisObj的scope是session也是不
準確的。首先注意到jsplet通過對象化實現了將狀態和行為抽象到一起,此后程序就擁有了對這個整體的控制權,在jsplet中存在著對象的生命周期控
制,對象的scope是自定義的,對象的生命周期是session的子部分,而不是整個session生命周期范圍內都存在。請注意一下這種控制策略帶來
的可擴展性。我們擁有了對象生命周期的控制權,依然可以采用無狀態設計,但在需要保持狀態的時候,可以做到。而在webwork這樣的action模型中
是沒有這種選擇權的。
引用: |
session過度使用是不好的 |
thisObj只是允許使用session,是否使用session可以自行決定,這是一種使能技術,而沒有object支持,結果是無法有效的使用。另外,請仔細看清楚,objectScope是一種非常精細的資源使用控制手段。
另
外不要把設計理念和性能混為一談。設計體現的是對概念的把握,能夠達到合適的抽象,而性能是實際實現過程中的限制。在概念能夠支持的情況下,可以采用技術
手段解決性能問題,或者退化到較低的層次,這是一種選擇權。而概念無法支持的情況下,就需要各種穿墻打洞的方法來實現。
thisObj重要的是概念,如果需要,它可以把狀態序列化到cookie或者dotNet那種參數中,這只是個實現問題。
引用: |
JSPLet Action 必須是 JSP ? |
當然可以是任何java類, JSP Action只是IEventListener接口的一個實現 。在jsplet最初的版本中,action只能寫在java文件中。稍后改為可以寫在jsp中也可以寫在java中
引用: |
WebWork的Action本身就是模型對象 |
這是WebWork弱的地方,它因為是基于action的,沒有對象化,所以只有以action作為模型對象的載體,無法捕獲多個action之間的狀態相關性。
完全無狀態的設計正是因為沒有合適載體造成的。而jsplet中thisObj可以看作是對session的局域化,是對session的分解。jsplet中的很多概念在webwork這種面向action的框架中都能找到對應,只是加上了很多限制并且變得模糊了。
引用: 沒有model1簡易(jstl+javabean) 沒有struts的"優雅" 定位模糊.
jsplet
是以非常精煉的方式實現對象化。再說一次,不要把jsplet的定位向那些開源框架上靠。jsplet的開發時間大概與那些開源框架同時進行的。仔細看看
設計中的可擴展性。xwork的所有特性jsplet都可以實現,而且jsplet多提供的部分就是對象化。
可 以使用 并不意味著必須使用,所有無狀態設計都可以一樣應用。jsplet是一種事件驅動設計,在這一點上,更像是Tapestry或者JSF。基于 actioin的設計是真正的無能使用session,它不敢應用session的原因是它對session沒有控制力。而在jsplet中對 session的使用控制是很自然的:當你需要對象的時候,當你需要這個狀態的時候,它才存在。它出現是因為需要它存在。在面向action的框架中,你 仍然需要解決狀態問題。只是框架無法提供支撐,自己解決而已。
我想,大概大多數人開發的程序都是CURD的堆砌,所以很難理解一個復雜的應用中的狀態管理的必要性。有了對象支持之后,才構成整個框架的概念上的完備性。