在最开始做可视化应用的时候，从来没有考虑过如何组织代码结构。后来开始接触了3层甚至N层，接触了UI映射、ORM映射，借鉴这些我自己也设计了O-O映射和控件关系映射。后来我接触了UI Composite Application Block（CAB）和SCSF，觉得其组合设计思想非常的不错，还花了2个月时间把OB和UI App Block源码看了一遍。首先我简单提一下界面组合的概念（SCSF概念很多有20几个，可以查一下微软官网，有很详细的文档），界面组合从字面的意思就是利用组合思想设计界面。在SCSF里面，一个UI=Shell + Views。一个Shell定义了界面布局及显示方式，它有ExtensionSite和Workspace组成，ExtensionSite类似菜单、导航栏扩展点，每一个模块都可以向这些扩展点添加菜单和导航项目；而Workspace则定义了内容显示方式，你可以在Workspace的某一个区域里面显示自己的视图，从而实现了由ExtensionSite、Workspace和View元素组成的界面。
最近在单位我们正在开发一个数据库监控控制台，用于监控数据库系统中内存、CPU、IO、数据库、Cache、Process、Transcation等。该监控终端需要监控SMP的DBMS和SDC的DBMS，二者在界面上有很多部分可以重用，但也有区别。监控控制台采用Flex（ActionScript/MXML） + Java实现，架构采用Cairngorm MVC组件。在界面设计时，我和另外一个工程师（他在美国东海岸，不知道是哪国人，很资深，级别是Architect）有一点分歧。我们设计思想介绍如下：
（1）我的设计思想：采用界面组合方式 + MVC，每一个界面由一个Workspace和一些View，Workspace定义了一个界面的布局、风格和呈现方式，View是一个可重用的UI组件，每一个Workspace和View都是单独一个文件（一个类），View产生的动作会触发一个事件由MVC的控制器来处理。为此，我将微软的CAB思想移到Flex上，设计了一个Composition SDK。该SDK的思路为：每一个可被组合的View是一个可单独运行、可重用的、由生命周期驱动显示数据的、可以被动态注入一些Hook的SmartPart。
（2）资深工程师思想：采用代码分离（类似ASP.NET代码绑定） + MVC，即每一个界面由两个文件组成，一个文件使用MXML设计（类似ASP.NET中的HTML代码）用于呈现界面元素，另一个文件是代码文件，用于监听界面元素的事件，将事件交由MVC的控制器来处理。
我对（1）的看法是，每一个View仅完成一个UI任务，简单而且容易复用，不过其缺点是需要引入一个Composition SDK。这个SDK对一般程序员来说，维护要求高了点。对（2）的看法是，这种方式无法实现UI组件的重用，粒度太大了。因为在我们的应用中，很多情况下，整个UI组件包括行为都可以直接重用，但是（2）这种方式无法做到；此外，一个复杂的UI，将其划分成一个MXML文件和一个代码文件，会使得页面更加复杂。
另一位资深工程师对（1）的看法是，引入新的设计思想，复杂，而且需要再维护一个Composition SDK，“简单就是美”，对于（2）的思想，他认为，这种方式一个印度年轻程序员很容易都可以自己设计出来的。
最近在单位我们正在开发一个数据库监控控制台，用于监控数据库系统中内存、CPU、IO、数据库、Cache、Process、Transcation等。该监控终端需要监控SMP的DBMS和SDC的DBMS，二者在界面上有很多部分可以重用，但也有区别。监控控制台采用Flex（ActionScript/MXML） + Java实现，架构采用Cairngorm MVC组件。在界面设计时，我和另外一个工程师（他在美国东海岸，不知道是哪国人，很资深，级别是Architect）有一点分歧。我们设计思想介绍如下：
（1）我的设计思想：采用界面组合方式 + MVC，每一个界面由一个Workspace和一些View，Workspace定义了一个界面的布局、风格和呈现方式，View是一个可重用的UI组件，每一个Workspace和View都是单独一个文件（一个类），View产生的动作会触发一个事件由MVC的控制器来处理。为此，我将微软的CAB思想移到Flex上，设计了一个Composition SDK。该SDK的思路为：每一个可被组合的View是一个可单独运行、可重用的、由生命周期驱动显示数据的、可以被动态注入一些Hook的SmartPart。
（2）资深工程师思想：采用代码分离（类似ASP.NET代码绑定） + MVC，即每一个界面由两个文件组成，一个文件使用MXML设计（类似ASP.NET中的HTML代码）用于呈现界面元素，另一个文件是代码文件，用于监听界面元素的事件，将事件交由MVC的控制器来处理。
我对（1）的看法是，每一个View仅完成一个UI任务，简单而且容易复用，不过其缺点是需要引入一个Composition SDK。这个SDK对一般程序员来说，维护要求高了点。对（2）的看法是，这种方式无法实现UI组件的重用，粒度太大了。因为在我们的应用中，很多情况下，整个UI组件包括行为都可以直接重用，但是（2）这种方式无法做到；此外，一个复杂的UI，将其划分成一个MXML文件和一个代码文件，会使得页面更加复杂。
另一位资深工程师对（1）的看法是，引入新的设计思想，复杂，而且需要再维护一个Composition SDK，“简单就是美”，对于（2）的思想，他认为，这种方式一个印度年轻程序员很容易都可以自己设计出来的。
因此，最终我们谁也说服不了谁。他在他的项目使用（2）的方式，我在我的项目使用（1）的方式，而我设计的Composition SDK他们也就没有采用了。为此呢，我也想过很多次，比较过很多次，但我还是觉得（2）的方式虽然简单，可满足不了我这个项目，因为这个项目需要重用很多View。看来，这两种方式各有优缺点，不知各位在设计UI应用的时候用的是什么方式。
本文转自道法自然博客园博客，原文链接：http://www.cnblogs.com/baihmpgy/archive/2009/08/30/1556836.html，如需转载请自行联系原作者
