UI5和WebUI的View和Controller是如何綁定的

UI5

例如我在UI5的界面上畫一個按鈕，點擊之后彈出一個Alert dialog。

在XML view里只定義了controller的名稱和事件處理函數的名稱。那么按鈕被點擊之后，controller的onShowHello被觸發。但是，這個controller的實例是什么時候被創建， 并且關聯到這個申明它的XML view里呢？

在XMLView.js里，我定義的XML view的源代碼被加載之后，XMLView會調用XMLTemplateProcessor， 解析XML view的內容，根據里面的control申明創建對應的UI5控件實例。下圖的變量_xContent.innerHTML即為上圖XML view的源代碼。

XMLView的實例通過工廠模式創建之后，XMLView源代碼里定義的controller名稱sap.ui.demo.walkthrough.controller.App，會賦到oView實例的字段_controllerName上。

View和Controller的綁定是通過這個方法createAndConnectController完成：

connect controller to view after controller and control tree are fully initialized

Controller的實例也通過工廠模式創建：

一旦connectToView執行之后，

oView和oController的關聯關系就建立起來了。

CRM WebClient UI

每個UI component view里有一個built-in的屬性controller, 指向這個view對應的controller實例。

在BSP的編程環境里，開發人員根本無需操心這個controller實例的初始化，直接用就行。

那么View的controller實例究竟在什么時候被框架初始化的？

要自己搞清楚這個問題，可以隨便找個BSP UI component做個實驗。我找的是PRDHS。在其View的controller CL_PRDHS_HEADER_IMPL的構造函數里設置斷點：

打開該view，從調用棧上下文即可得知BSP框架在什么地方初始化controller實例的。記下這個實例在ABAP runtime的地址編號4633:

同UI5邏輯類似，在CL_BSP_PAGE_BASE~CREATE_PAGE內部，第190行創建controller的實例并將其同View實例建立關聯關系。

最后運行時View的controller實例4633和之前我們在PRDHS/Header的controller CL_PRDHS_HEADER_IMPL的構造函數中的me指針4633一樣，證明兩個變量指向的是同一個實例。

另外，UML 模型里的 association, aggregation 和 composition 的區別，大家能分清嗎？

UI5

UI5使用Association和Aggregation描述控件之間的關系。

Aggregation：parent和子控件在lifecycle上存在依賴關系：

When a ManagedObject is destroyed, all aggregated objects are destroyed as well and the object itself is removed from its parent. That is, aggregations won’t contain destroyed objects or null/undefined.

比如UI5的轉盤控件Carousel: 一旦轉盤被析構，里面顯示的page當然也沒有繼續存在的意義了，需要跟著被析構。

而Association描述了在lifecycle層面的一種soft dependency關系:

Managed associations also form a relationship between objects, but they don’t define a lifecycle for the associated objects. They even can ‘break’ in the sense that an associated object might have been destroyed already although it is still referenced in an association.

最明顯的例子就是控件和其label的關系，比如button和label：技術上來說，可以彼此分開獨立存在。

CRM

CRM的Genil model存在三種類型的relation，可以在doman CRM_RELATION_KIND里查看：

區別：

Association: Link between any kind of objects. Can also be defined across components with root or access object as target. 依賴關系最為loose的一種relation，可以用來連接跨model之間的節點。

Aggregation: Binds child objects to a root object. Only access and dependent objects can be aggregated. 只適用于同一模型的節點之間的關聯。

Composition: Like an aggregation, but composed child objects always exist. 特殊類型的Aggregation。目標節點的Cardinality為1或者1…n

S/4HANA

只有兩種：association或者composition。Composition的含義同CRM里的aggregation，而association的含義同UI5和CRM中的association一致。

C4C

只有兩種: association或者composition。C4C的這兩種relation多了一個限制：relation的目標BO必須和源BO在同一個部署單元Deployment Unit，或者目標BO位于Foundation部署單元內。

Association的語法如下圖：

association的multiplicity只支持[0,1]或者[1,1], 如果不顯式指定，默認為[1,1].

C4C relation的一個特色是，一旦申明了一個子節點之后，系統會默認生成一個對應的composition。

下圖第4行代碼會自動生成一個[0,n]的從root節點到Item節點的composition。

ABAP ERP UML XML 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。