前面分析了常用的5個頁面部件
正常情況下有這5個部件就足夠了
但是前面的5個部件，單獨使用都沒有任何意義，可以將這5個部件比作原材料，
那么我們要加工成我們需要的<<通用頁面模型>>(成品)
我們一般情況下到底需要哪些通用的頁面模型呢？
我這邊總結歸納了，一般企業數據庫應用系統開發80%的頁面模型，如下圖：
UI1、列表模型
一個項目幾乎60-80%都是這樣的畫面
根據查詢條件、查詢出結果顯示在列表上，同時提供些操作功能
基本構件如下圖：
示例：
如上圖的示例：就是典型的列表畫面
主要有三部分組成
1、頂部的功能按鈕 ----對應的前面分析的部件就是 “功能部件”
2、中間部分是查詢輸入框----對應的前面分析的部件就是“查詢部件”
3、下面部分是列表顯示功能-----對應的前面分析的就是“列表部件”
UI2、編輯頁面模型：
實現數據的新增和修改功能的頁面
提供最基本的用戶錄入控件
提供功能按鈕實現人機交互，比如說 保存、復制、刪除等等
部件構成圖如下：
真實示例：
如上圖所示的編輯頁面模型在一個項目中是非常常見的
既然重復率這么高，我們有必要抽象出這樣的一個頁面模型
將公用的部分封裝在這個模型中，不一樣的地方，通過配置手段來搞定
這樣我們開發出這樣一個頁面模型，就能應對整個項目中您肯能面對的10個，20個甚至更多的這樣的編輯畫面
具體如何實現后面會探討，在這里 我們找到了需要抽象的頁面模型
UI3、列表編輯模型
這是一個簡單組合模型
構成如下圖：
示例：
如上圖，這就是一個列表編輯頁面：
其實就是講UI1和UI2整合在一個畫面中
在我們的軟件開發過程中，可能需要這樣的維護畫面
通常復雜的、維護內容較多的頁面，我們都是點擊新增或者點擊修改，跳轉到、或者彈出一個新的畫面進行數據維護
一些簡單的畫面，客戶可能需要像上圖一樣 直接在同一頁面實現所有的增刪改查功能
UI3 的構成是 UI1+UI2
具體UI2保存成功后肯定要刷新UI1 列表頁面模型中的數據，這里面的數據協調機制由UI3來完成。
UI4、樹形頁面模型
前面也分析了樹形部件，那它的使用場景呢？別急 看下圖
UI4-樹形頁面模型構成：
示例演示：
如上圖的功能菜單維護就是典型的樹形模型畫面
UI4-樹形頁面模型 主要是用來實現有父子關系的資料維護功能
如左側使用樹形部件來顯示數據，這樣比較直觀
右側，我們不會重復開發代碼，我們直接使用UI2-編輯頁面模型
如果<<UI2-編輯頁面模型>>是成品的話，這個話 對的，它的確可以作為最終的用戶使用頁面
但是同時<<UI2-編輯頁面模型>>也可以看做是半成品，如在<<UI4樹形頁面模型>>中就是一個組件構成
能夠如此方便的實現嵌套，這都完全得益於Silverlight的強大之處
UIElement可以隨意的套來套去
UI5-關系頁面模型
關系頁面模型：顧名思義就是用來維護關系的一種特殊頁面
比如說維護一個用戶對應的角色
一個用戶可以有多個角色
通常我們在這樣的畫面中提供角色的數據列表控件，供勾選，選中就是當前維護的這個用戶的角色
解釋一下：如上圖 編輯部件，就是用來顯示，當前正在維護的對象
查詢部件，用來檢索查詢，比如說查詢角色，可以輸入特定的查詢條件來定位角色
列表部件，查詢出來的結果，供選擇
也許，留意的同學會發現這個所謂的關系頁面模型和 UI3列表編輯頁面非常相似的
對的 大體一樣，唯一不一樣的是 這里的列表部件，查詢后，要自動勾選中那些已經數據要設置的對象了的數據行
UI6-復合模型
其實你也接觸了一個簡單的復合模型UI3-列表編輯模型
這里講的復合頁面模型，是一個更加復雜的，功能更加強大的頁面模型
上述總結的所有頁面模型 都可以被 復合模型來使用。
構成圖：
示例：
如上圖的程序 就是一個復合的頁面模型的典型應用
首先它組合了 ：如上圖的歸並關系表頭： UI2 編輯模型
組合了：如上圖的歸並后料件：UILIST 模型
等等
好了廢話不多說，至此我們分析總結出了我們需要重點開發的如上的6個頁面模型
開發完這個6個頁面模型，這樣就能解決80%的軟件編碼問題
所以按照上面的分析
我們會重點開發如下圖的5個部件
用上述的5個部件組件我們的頁面模型
有如上圖紅色框線中控件就是我們總結的一系列頁面模型，使用它我們就能實現80%軟件無需編碼，全部使用配置來實現。
我們使用同一配置開發平台進行軟件配置定義，最終軟件配置開發平台會產出XML,
然后將這個XML交個上述頁面模型，頁面模型會根據XML中描述定義，自動生成畫面。無需手動進行代碼開發。