基于CAB和SCSF设计智能客户端（一）翻译

介绍

这篇文章的原创者是RACON Software GmbH，它是上奥地利州Raiffeisen银行集团的一个软件工作站，专门为设计和实现复杂智能客户端提供一些架构上的指导，这些智能客户端是基于微软patterns&practices group提供的CAB和SCSF。

这篇文章的出发点就是帮助RACON Software GmbH的架构师和主要开发人员设计及实现一个新的银行桌面复杂智能客户端。之所以产生这个桌面应用程序的想法，是因为在日常业务中，银行职员经常使用很多不同的基于客户端的应用程序。一开始，发现问题是因为每一个客户端都不一样的工作，职员们每天都因为在这些不一样的工作方式中来回切换而头疼不已。而且，应用程序没有统一，导致许多事情需要在不同的应用程序中多次重复完成。从IT的角度上看，管理多个应用程序是相当困难的，通用功能的重复使用是几乎不可能的。因此，RACON Software GmbH想要创建一个通用程序来作为银行应用程序的平台。每一个银行程序都可以被这个平台所管理。这些程序最终都被模块化，可以动态的加入到这个平台中，可以根据用户的安全性考虑进行加载和初始化，因此用户也只能看到它所允许的其他部分。所有不同的应用程序都被嵌入到一个中心模块中，它们使用的通用服务由像银行桌面的平台来管理，这使得管理多个应用程序相对容易，通用功能也可以重用。由于模块是动态可配置的，不同的应用程序组件松散耦合，彼此不互相依赖，最关键的需求是如何实现这些组件之间的通信。最后，这个银行桌面综合系统的想法产生了。它为银行机构的每个职员提供一个类似的客户端，这些客户端被整合到综合系统中，综合系统针对完成特定任务的角色进行相关配置。因此，这个银行桌面系统是关于智能客户端的一个很好的例子，这个客户端本身也很特殊，我们称之为复杂智能客户端。微软用于设计和开发复杂智能客户端的技术包括CAB（Composite UIApplication Block）和SCSF（Smart Clients Software Factory）。这篇文章就是关于这些技术的。

第一部分：针对复杂智能客户端的架构指导

第一部分主要是介绍基于CAB和SCSF创建复杂智能客户端的架构性指导。它专门帮助你识别和构造你的复杂智能客户端组件，并找到一种方法对他们进行封装。

专业术语

CAB：是由微软patterns & practices group提供的一个灵活的程序集，用于创建复杂的、模块化的智能客户端应用程序。这个程序集主要提供如下功能：

动态的装载具有协作关系的独立模块到一个共同的平台中；

通过事件代理实现模块之间及模块内部之间的松散耦合通信；

实现灵活的命令模式；

实现服务于MVC模式的基础类；

建立一个框架，用来提供诸如验证服务、授权服务、模块定位、模块加载服务等。

CAB应用程序是基于用例驱动的，每个用例通过MVP或MVC来实现。中心的客户端服务通过CAB提供的基础服务进行加载。

WorkItem：从技术上看，WorkItem是用来管理实现一项具体功能的多个对象的容器。这些对象包括状态对象，视图及控制层，命令等。在WorkItem的上一层视图，它是对一个特定用例在逻辑上的封装类。它可以被看成一个用例管理员，对用例的各个方面都很清楚。就像这样，一个WorkItem可以掌握用例相关的每个部分的状态，比如Views，或者下一级用例。更进一步说，它是它所负责的用例（或者是下一级用例）的入口点。

Service：Service对整个应用程序的共有功能进行了封装，这些共有功能也可能是某个模块共有的，或者是某一级WorkItem中的多个WorkItem（例如该级WorkItem的下一级WorkItem）。典型的是如验证和授权的安全性服务，以及拥有交互和离线能力的Web service代理。

Module：多个逻辑上相关的WorkItem可以被放到一个单独的部署单元，即模块。基于CAB的智能客户端程序基本上是在模块的级别上进行配置。因此，使用适合的颗粒度对WorkItem进行封装是最关键的。

ProfileCatalog：这个基本目录只是一个配置文件，指定哪个模块或服务需要被装载到程序中。这个配置文件默认只是驻留在应用程序目录中的一个XML文件，它规定了哪些模块需要装载。通过编写和注册一个自定义IModuleEnumerator类，你可以重新指定一个新的位置来加载配置文件，比如通过Web service。

ModuleLoader：由CAB提供的通用服务，负责装载ProfileCatalog定义的所有模块。它仅仅是遍历ProfileCatalog，装载每一项对应的程序集，然后找到程序集中的ModuleInit类。

ModuleInit：每个模块都包含ModuleInit类，它负责加载模块中所有的Service和WorkItem。（除了Services和WorkItems，它还负责其它方面，比如针对shell的扩展用户接口；更多的信息可以参见表中后面关于UIExtensionSite的描述。）

Shell application：Shell应用程序负责平台的初始化，在平台中最为重要。它负责根据配置进行模块的加载和为智能客户端启动基本的服务，此外还负责启动主窗体。

Shell：它是应用程序的主窗体，为所有加载的模块提供公用的用户接口。RootWorkItem一直驻留在Shell中，它是进入应用程序其他部分的入口，比如服务，模块，以及被这些模块生成并注册的WorkItems。

Workspace：它主要负责放置和显示由WorkItem生成的用户界面元素。通常Workspace被添加到Shell中（或者是该级WorkItem所在的扩展窗体）作为部分UI的容器，这些UI容器将要装载由不同级别的WorkItem生成的UI元素。

UIExtensionSite：它是Shell为放置菜单、工具条、状态条预留的扩展部分。和Workspace不同的是，它们作为UI的部分，并没有完全被WorkItem包含；它们是可扩展的（比如增加一个新的菜单项）。

Command：它是CAD用来实现命令模式的基本类。CAB支持自定义命令或者通过[CommandHandler]属性声明方法生成命令，这些声明后的属性作为命令的句柄。你可以为一个命令注册多个调用者（比如多个控件可以使用一个单击事件）。

EventPublication：基于松散耦合事件的事件发布方法。事件发布者通过.Net中的[EventPublication]属性实现事件发布，通过URIs（唯一字符串）唯一标识。CAB将这个URIs告知事件订阅者订阅事件。事件订阅者必须有对应的方法通过[EventSubscription]属性进行标记，方法名称和使用了对应[EventPublication]的事件名称相同。

EventSubscription：它和EventPublication互相对应。订阅事件的类需要实现一个事件句柄，而且需要匹配EventPublication标记的方法名称，事件句柄需要通过[EventSubscription]属性和发布者的URIs（构造函数的参数）说明，这样CAB才能确保每次发布者触发事件的时候，它所有的订阅者都能被通知。

Model：它是WorkItem中的业务对象（客户端的）；例如顾客，银行账户或贷款。

View：它是.Net的常用用户控件，负责显示部分或整个Model，并且允许用户通过界面修改它的所展现的内容。代表性的，View只负责界面上的逻辑，业务逻辑由presenter或者controller负责。

SmallPart：它是带有[SmartPart]属性的.Net用户控件，可以选择性的实现ISmartPartInfoProvider接口。本质上，SmartPart就是关于控件本身的附加信息，比如标题或描述。

Controller：它负责业务对象的逻辑实现。一个Controller只负责一个Model，这个Model可能对应有多个View。可参见MVC模式。

ObjectBuilder：是CAB的基本组件，像一个工厂，根据不同的策略生成不同的对象，或者自动化实例对象，在生成对象的同时完成依赖对象的初始化。本质上，ObjectBuilder是对象工厂，依赖注入容器和策略模式实现的混合体。

DependencyInjection：它是一种设计模式，通过工厂自动化创建对象或者同时初始化依赖对象的属性及成员。ObjectBuilder实现了这种模式。