对于一些较小的项目，具备一定经验的开发人员应该能够设计和构建出便于进行维护和扩展的应用程序。但是，随着功能模块数量（以及开发维护这些部件的人员）的不断增加，对项目实施控制的难度开始呈指数级增长。

SailingEase WinForm 框架为您提供了针对此问题提出的解决方案。在本文中，将对基于SailingEase WinForm 框架的复合应用程序的定义进行解释，并简要说明如何才能构建一个基于 SailingEase WinForm 框架功能的复合应用程序。

传统的单一应用程序

传统的单一应用程序每个控件都紧密耦合在一起，UI 中存在大量用于协调各个部分的逻辑。控件之间还存在着相互依赖关系。

由于存在这些依赖关系，因此无法通过某种简单的方法将应用程序分解成可在其中分别开发各个不同部分的窗体。虽然可以将所有用户控件都放在一个单独的程序集中以提高可维护性，但这种做法只是将问题从主应用程序转移到了控件程序集，治标不治本。在这种模型中，进行重大更改或引入新功能都非常困难。

基于 SailingEase WinForm 框架的复合应用程序（插件式应用程序）

基于 SailingEase WinForm 框架的复合应用程序由运行时动态发现和构成的松散耦合模块组成。模块包含代表系统的不同垂直片段的可视和非可视组件。可视组件（视图）被组合在一个常规外壳中，可用作应用程序所有内容的宿主。复合应用程序可提供各种服务，将这些模块级组件结合在一起。模块可提供与应用程序的特定功能相关的其他服务。

从较高的层次来看，复合应用程序是“复合视图”设计模式的实现，此模式可描述包含子项的视图的递归 UI 结构，这些子项本身也是视图。这些视图然后通过某种机制组合起来 — 通常是在运行时而非设计时静态组合。

模块会影响在其中创建主复合视图（也称为外壳）的视图。模块永远不会相互直接引用，也不会直接引用外壳。相反，它们会利用服务在彼此之间以及与外壳之间进行通信，以响应用户操作。

使用模块来组成系统有很多好处。模块可聚合来自同一应用程序中不同后端系统的数据。此外，系统可随着时间的推移更加方便地发展演变。在系统需求发生变化而需要向系统中添加新模块时，与非模块化系统相比，模块化系统面临的冲突要少很多。而且还可以对现有模块进行独立性更强的改进，从而改善可测试性。最后，模块可由不同的团队开发、测试和维护。

一个典型的基于 SailingEase WinForm框架的应用程序

创建基于 SailingEase WinForm 框架的应用程序

引导程序和容器

使用 SailingEase WinForm 框架构建复合应用程序时，首先必须初始化几个核心复合服务。这就引入了引导程序。它可以执行发生复合所需的全部功能。在许多方面，它都类似于应用程序的 Main 方法。

对于容器，指的是控制反转 (IoC) 容器/依赖关系注入 (DI) 容器。容器在应用程序中起着关键作用。容器存储着应用程序中使用的所有应用程序服务。它负责在需要的位置注入这些服务。

在配置容器的同时，还会自动注册几个核心服务（如事件聚合器），基本的引导程序允许您覆盖其中的任何服务。例如，自动注册 ImoduleLoader 服务。如果在引导程序中覆盖 ConfigureContainer 方法，即可注册自己的模块加载程序。

模块的加载

在引导程序中，通过覆盖方法 GetModuleCatalog 即可加载所需的模块，除了通过 ModuleCatalog 的 AddModule 方法来加载模块之外，，可以在此实现其它任何所需的模块加载方式。

定义并实现一个模块

在基于 SailingEase WinForm框架的应用程序中，模块是复合应用程序的分离单位，可将其部署为单独的程序集（尽管并非必需）。模块包含了大部分的功能。

这是一个基于 SailingEase WinForm框架的应用中的一个模块，StartPageModule.cs是实现 IModule 接口的类。此接口仅包含一个方法，称为 Initialize。如果把引导程序看作应用程序的 Main 方法，那么此处的 Initialize 方法就是模块的 Main。

在该模块的构造函数中，我们取得 IUnityContainer 容器，事件聚合器 IEventAggregator ，以及工作区服务 IWorkbenchService。

IUnityContainer，IEventAggregator和IWorkbenchService它们究竟从何而来？我是否要将逻辑硬编码到模块的初始化代码中？