前面分析了常用的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中描述定义，自动生成画面。无需手动进行代码开发。