跳到主要內容

Web Dynpro 前後端資料流動機制 (Dataflow)

在Web Dynpro中提供3種資料流機制[1]，只要適當地設定，可以不用寫程式就將畫面、中間層控制器(controller)到後端模型物件的資料自動化地、牢靠地綁在一起，使得不管前後端某一方有資料變動，變動部份都會自動地流動來保持一致性，使得前後端都能存取到同一份資料。

context
關鍵元件是 context，每個controller都有一份屬於自己的context，它扮演MVC架構中的M (model)，web dynpro的實做方式比較像是該controller的「資料空間」，它由node(資料節點）與attribute（資料屬性）組成，controller可以透過wdContext這個預先產生好的 shortcut variable（捷徑變數）去取得context的資料內容。
context中必須要建立node才可以儲存資料，一個node代表一個collection(集合物件)裡面仍可以含有node, attribute，node裡面的一份資料實體就是一個element，一個node可以有一個或多個element（這部份可以透過cardinality property設定），其結構就是該node所包含的結構。

data binding
此種機制可以將UI元件的資料跟context中的某個node或attribute綁定在一起，context中的改變會自動更新到UI元件上，UI元件的改變也會自動寫入到綁定的context node(or attribute)中。通常UI元件所綁定的node（attribute)是由component controller對應過來的。

context mapping
每一個controller都有屬於自己的context(資料空間)如果要達到彼此共享資料，則要透過context mapping機制，一旦mapping設定好，則會在另一個context產生一個同樣的結構的node，兩邊的controller會存取到的是同一分資料，任何一邊的資料更動都會散佈到設定好mapping的node。
不過在web dynpro裡，只允許將custom controller or component controller的node對應到view controller去，不允許從view controller對應回來，主因是嚴格遵守MVC的架構原則。

model binding
將後端model class的資料綁定到context中model node的機制，當我們向後端系統發出呼叫（web service or BPAI），其結果會自動被綁定到特定的model node。


3種資料流動機制圖

這樣的資料流動機制再配合上一致的context API及自動產生model class，web dynpro為開發者省下許多定義model物件、傳遞model物件的時間，開發者可以將時間集中在UI互動邏輯上。

Reference:
[1]MatthiasWeidlich, Web Dynpro:Context Mapping and Model Binding, Seminar System Modeling 2005, Hasso-Plattner-Institute for Software Systems Engineering
[2]Chris Whealy, Inside Web Dynpro for Java, SAP Press

標籤：

留言

張貼留言

這個網誌中的熱門文章

XMind使用心得

使用FreeMind有好一段時間，不過畫面單調一直是我不滿意之處。 XMind在畫面上好看很多，節點形狀樣式、分支線樣式有多樣選擇，也可以匯入FreeMind的檔案。 類似Excel般，工作頁活頁的概念也很不錯，可以將多個相關的心智圖存在一起。 可以某個分支為中心來檢視的功能也很令人激賞，完全符合心智圖那種可見樹、可見林的特性。 不過使用上有幾項缺點: 1.不能設定節點的預設文字大小。 預設應該是10點字，太小了，但是「喜好設定」內沒有地方可以修改，需要每次自己加大字型，很麻煩。 2.沒有加大字型的動作可以設定快速鍵。 我喜歡不只是用顏色，還有用字型的大小來凸顯主幹、分支的差別，不能快速的增大、縮小字型很不便。
2 則留言
閱讀完整內容

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展，所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺，仍有其優勢，所以我想決定性的因素會比較是 開發者的偏好 及 專案的特性 。你可參考下面的比較來決定哪種方式比較適合你。 優勢比較 MVVM ViewModel 較不易受畫面變動影響。 因為 ViewModel 沒有變數直接指向 ZK 元件，因此若是畫面上有元件更改，ViewModel 一般不需要修改 ViewModel 較易於在不同頁面中重用。 因為 ViewModel 只包含資料跟業務邏輯，若是不同頁面需要的資料跟業務邏輯相同，就可以重用同一個 ViewModel 例如 A 頁面按按鈕執行搜尋，B 頁面點選單執行同樣的搜尋，則可以重用同一個 ViewModel 中的 command，只是兩個頁面 data binding 寫在不同的元件上。 畫面較易於重用（易於模組化）。 透過 shadow component 跟 template 機制，可以將一段頁面的片段做成可以接受傳入參數 套用 Responsive Design 的成本較低。 通常需要針對不同裝置設計不同版面，但是顯示的資料內容大同小異，因此 ViewModel 多半可以重用 易於套用美工所設計的畫面，或是網路上現成的元件。 易於整合第三方 javascript library 或 widget。 因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通 ViewModel 的可測試性較好。 因為 ViewModel 不需要繼承特定類別跟實作特定介面，可以輕易地執行單元測試 MVC 操控元件方式直覺好學、易懂。 MVVM 控制元件較不直接，需要了解 zk framework data binding 的行為 可以完全使用元件所提供的所有 API。 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox , Listbox.renderAll() , Popup.o...
張貼留言
閱讀完整內容

Code Complete, 2ed (中譯：軟體建構之道) 讀後心得

Code Complete, 2ed (中譯：軟體建構之道) 讀後心得 雖然以前在學校有修過軟體工程，但是說實在現在我對建構軟體的整個概念都來自於兩本書：「人月神話」(The Mythical Man-Month)、Code Complete[1]。我畢業後第一份工作是軟體研發工程師，我們公司所開發的系統大約有近百位工程師共同維護，當然各有依功能與專業知識將系統劃分不同的區 塊來維護，在面對大型的系統與這麼多人寫程式是以前在學校沒有遇過的，因此也開始思考怎樣才是好的軟體開發方式。從大學好友那探聽到了Code Complete這本書，花了上千元買了英文版，（現在中文版已出，簡體版聽說只要三分之一的價錢）認真讀了幾篇之後，真是如獲至寶，於是自己讀過後，還跟同事組成讀書會一同研討這本書。 作者 Steve McConnell (個人Blog http://www.stevemcconnell.com/ )著作不算量大，但是我看過的幾本質量都很好，印象中他曾經在微軟工作過，後來成立一家軟體顧問公司 Construx Software 。 這本書(書本網站 http://cc2e.com/Default.aspx )的討論主題很廣泛，但是並不空泛，從最小的、最基本的如何寫出好的程式， 例如函式(routine)、註解 (comment)、變數的命名等，也談整個軟體建構的過程除錯、測試，最後也談到軟體工程師個人能力與技術生涯的發展，算是各方面都有提及。但是我比較 建議有半年以上的實際程式經驗來讀這本書比較適合，我自認為如果我在學生時代接觸本書，可能沒有什麼太大的感觸，因為面對的都是小格局、人數少的小系統， 書中所探討的原則與例子，很多時候沒有團隊開發或大型系統的經驗，很難體會。但稍有經驗的人，看完之後保證在程式撰寫與軟體開發方面的觀念會有很大的提 昇。 Table of Content Laying the Foundation 1 Welcome to Software Construction 2 Metaphors for a Richer Understanding of Software Development 3 Measure Twice, Cut Once: Upstream Prerequisites 4 Key...
張貼留言
閱讀完整內容