内容


设计复合应用程序:设计模式

Comments

编辑注:本文是有关复合应用程序系列文章的第三篇,developerWorks 将在未来几个月内继续发表该系列文章。请查看前几期文章 “设计复合应用程序:组件设计” 和 “IBM Lotus Notes V8 中的 Lead Manager 应用程序:概述”。

复合应用程序是面向服务架构(SOA)和上下文协作策略(contextual collaboration strategy)中的关键要素。当今市场竞争日趋激烈,企业必须快速响应不断变化的用户需求,而复合应用程序可以为企业提供业务灵活性。复合应用程序由一些用户界面组件集合而成,这些组件通过彼此松散耦合支持组件间通信。

组件可以在多个复合应用程序之间实现重用。将多种技术集成到单个应用程序中可以带来显著的业务价值。这提供了更好的灵活性,使企业能够保护和扩展其现有资产,并允许企业使用应用程序快速且经济有效地响应新出现的业务需求,这些应用程序比起在多个应用程序开发环境来说要容易创建得多。

这种松散耦合的复合应用程序架构还能使不同位置的各个团体利用彼此的工作成果并进行互操作。例如,某个部门可能正在为公司开发财务应用程序,而另一个小组则在开发潜在客户跟踪应用程序。复合应用程序的设想就是将潜在客户跟踪应用程序中的某些组件添加到财务应用程序中,从而能够在财务上下文中查看有关的资产视图。类似地,潜在客户跟踪应用程序也可以合并来自财务应用程序的组件,从而在资产上下文中提供财务信息。随着企业开发的复合应用程序越来越多,集成已成当务之急。集成的目标就是实现整体作用大于个体作用之和。

IBM WebSphere Portal 开发人员已经非常熟悉复合应用程序模型。这种方法已经被扩展到 IBM Lotus Notes V8 中,使 Lotus Notes 开发人员能够将 Lotus Notes 应用程序作为复合应用程序中的一个或多个组件。IBM Lotus Domino Designer 实现了进一步扩展,可以利用属性代理并提供更加直观的用户环境。Lotus Notes V8 还支持包括 Eclipse 组件。复合应用程序可以将任何 Lotus Notes 和 Eclipse 组件组合在一起。这些组件可以组合在同一个用户界面(UI)中,即进行界面(on-the-glass)集成,或者进行扩展以使用属性代理,从而实现组件之间的互操作。可以使用 Composite Application Editor 或者 WebSphere Portal Application Template Editor 来定义复合应用程序。

复合应用程序的组件开发不同于传统的 Eclipse 或 Lotus Notes 应用程序开发。复合应用程序需要创建具有足够灵活性的组件,以便日后在部署到应用程序中时不需要进行大量重复工作。本文将讨论在设计此类组件时需要用到的方法以及此过程采用的最佳实践。

先决条件

本文要求读者熟悉 IBM Lotus Notes 的复合应用程序,因此回顾 IBM Lotus Domino Designer Help 中有关复合应用程序的章节将非常有帮助。

您还应该回顾 developerWorks Lotus 文章 “IBM Lotus Notes V8 中的 Lead Manager 应用程序:概述” 和 “设计复合应用程序:组件设计”,其中介绍了有关组件设计的高级内容。这些文章讨论了以域为中心的组件和上下文域组件,它们本身都是元模式。

开发模式

在开发过程中,我们经常使用类似的方法解决相似的问题,这种思想得到了很好的推广。从早期的应用程序到面向对象编程,人们发现,在很多环境中,按照模式完成工作非常有效;换句话说,就是为很多应用程序中的常见问题提出通用的解决方案。复合应用程序的设计和开发也是如此,并且,本文将探讨在这方面有帮助的模式。

为了使内容更有条理,我们将模式的类型分为不同的类别:

  • 定义常用组件类型的模式
  • 根据组件布局和互操作方式定义组件集合的模式
  • 定义应用程序或整体设计方式的模式,可用于构建整个复合应用程序或复合应用程序套件

组件模式

本节描述各种常见的组件类型。

选择组件

选择组件(selection component)允许值跨越多个信息域。例如,一条出差请求提交可能包括一个引用了 Human Resources 记录的员工编号,或者包含一个识别会计程序包中控制中心的成本中心。出差请求应用程序在其业务逻辑中跟踪这些值,仅供参考,且业务逻辑中会与其他信息域发生交叉。在 UI 层,值字段如果不是由这个信息域定义,那么通常只是用户必须填写的输入框,这就有可能产生输入错误。

每个应用程序都可针对其域内的信息创建一些选择组件。由于应用程序具有其域内的所有信息,因而可以为用户提供所有适当的方法供选择。这是一种典型的上下文域组件,在 developerWorks Lotus 文章 “设计复合应用程序:组件设计” 中曾讨论过。在上面的例子中,Human Resources 应用程序会生成一个选择组件用于选择员工,可以根据姓名、电子邮件、电话、位置或应用程序跟踪的任何其他字段进行搜索。组件输出可以是这些字段中的任意一个,也可以是用于出差请求的员工编号。

可以使用下面任一种方法呈现组件:

  • 通过 UI 形式呈现。UI 位于应用程序页面的边缘或指示板中,主要记录就是在这里复合的。复合区域的编辑字段被绑定到选择组件。如果值是已知的,只要将其输入编辑器即可;否则,可使用选择组件进行选择和搜索,之后将得到的值填充到编辑器中。
  • 通过具有小型 UI 的不可见组件呈现。除了处理和传播有关的索引值时用到的属性和操作之外,还有另一个值用于通知组件显示其 UI。这是一个弹出式对话框,其中包含组件要呈现的相同的搜索选项。虽然这要求在发送组件上使用 Lookup 按钮(因此耦合松散度降低),但是可以更有效地使用 UI。搜索面板只有在需要时显示。

信息组件

信息组件(information component)提供有关单个数据记录的详细信息。它可以是详细的完整视图,显示记录中的所有数据元素,也可以是仅显示高级信息的摘要。它还可以针对记录中的特定信息子集。在 developerWorks Lotus 的 Lead Manager 样例应用程序 中,有很多用于 Companies 和 Leads 的信息组件。其中每个信息组件都有一个包含完整 Lotus Notes 表单的 Detail 组件,以及仅包含基本信息的 Summary 组件。

和选择组件一样,也可以为信息组件设置最小化的页面显示。激活组件之后,可以通过编程或 UI 创建一个包含信息的弹出对话框。这可以节省屏幕中的操作区域,同时不会损失功能。这类弹出窗口经常用于 Lead Manager 样例中。

启动程序组件

启动程序组件(launcher component)是另一种上下文域组件。它并没有通过添加信息来增强包含应用程序(containing application),相反,它添加了功能性。通过连接,可从包含应用程序的上下文中检索数据元素并显示针对这些信息的处理选项以及自身域的处理步骤。它可以显示自己的 UI 供用户从中选择操作,也可以接受某种操作。这允许另一个以域为中心的组件命令它执行类似于弹出式选择组件的操作。虽然耦合度没有达到理想的松散度,但是实现了更加紧密的 UI。如果组件能够通过直接操作或用户交互而工作,那么可以由应用程序装配程序作出决策。

例如,未来版本的 Lead Manager 应用程序要求将潜在客户信息域与邮件和即时消息域联系起来。邮件组件公开可以编写邮件的操作,当该操作被触发时,将启动一个新的邮件备忘录。当查看潜在客户或公司信息记录时,UI 中的某个选项可以将邮件消息发送给潜在客户或公司的联系人。组件通过触发与邮件组件的连接完成这一操作。通过类似的技术为您提供启动即时消息会话的选项。

由于很多潜在客户来源于邮件,所以您可以创建一个启动程序组件,它处理很多属性(这些属性对应于针对新潜在客户的输入条目),并公开一个 Create Sales Lead 按钮。当单击这个按钮时,将切换到潜在客户应用程序,同时组件调用 UI 创建新的潜在客户并使用可用信息进行填充。可以在您的邮件模板(或与启动点相关的其他数据库)中部署这个组件,同时将当前选中的邮件信息的 To 字段连接到启动程序组件的 Salesperson 属性,将 From 字段连接到 Customer 属性。查看邮件消息时单击 Create Sales Lead 选项,将显示可创建新潜在客户的 UI,其中已经预填了 Salesman 和 Customer 字段。

计算组件

计算组件(calculation component)的功能是输入一个或多个值后能够生成一个或多个派生值作为输出。它可以使用多种形式,包括简单的一般性算术计算和上下文域查找。在很多情况下,这些组件不具备交互式 UI。组件可以保持空白并置于应用程序中不引人注意的区域,或者用来显示徽标或其他标志。

以一个简单的数学组件为例,它使用以逗号分隔的值列表作为输入,并将这些值的总和作为输出。如果您的列表组件能够将一列数据作为一组值导出,那么该组件将被连接到求和(summation)组件,而将结果发送回另一个组件以显示总和。

计算组件的另一种表现是一种特殊形式的选择组件。假设您有一个采购订单应用程序。超过一定数量的采购必须征得经理同意。订单提交部分要求填写经理的姓名和邮件地址。在此处需要使用选择组件,但是用户仍有可能选择错误的经理人选。作为一种替代方法,您可以从员工数据库应用程序中开发一个域上下文组件,它可以接受包含员工姓名的操作,然后发布有关该员工的各种信息。应用程序装配程序随后将经理信息连接到表单的输入部分。您甚至可以将表单的输入字段修改为计算字段,从而防止用户输入错误。

除呈现数据以外,这些组件还可以呈现业务逻辑。在上文的例子中,假设每个员工的支出限度都不相同,并且还取决于内部制度(如地区)。财务信息域的计算组件可以捕获员工姓名并返回该员工的支出限度。采购应用程序中以域为中心的组件能够实时检查这个限额值,而不是等待后端进程对这个值进行标记。

这种组件的特殊形式可以处理数据类型转换。为组件的属性和操作定义强数据类型可以实现更加简单和准确的应用程序装配。某些情况下,您可能需要使用具有弱类型属性和操作的通用组件。一个简单的计算组件可以使用某种类型的操作并发布数据相同但类型不同的属性。在部署时,可将这些实用组件部署为不可见或具有最小化 UI,并作为两种不兼容组件(例如,一个组件具有可以处理邮政编码的操作并发布包含城市名和州名的字符串)之间的格式转换程序连接。

聚合组件

某些复合应用程序可能由一些页面组成。可以通过由平台提供并受 Composite Application Editor 支持的跨页面连接(cross-page wires)在页面之间维护简单的应用程序上下文。当希望修改某个页面上下文时,将通过跨页面连接将一个属性连接到另一个页面中的某个操作。激活这个属性将导致页面发生修改并将上下文传递给新的页面。在更为复杂的场景中,仅仅使用单个项维护页面以及将页面转换与上下文传递相结合并不能够满足需求。上下文需要跟踪多个值,并且页面转换可通过使用其他用户操作而发起。

聚合组件(aggregation component)是一种数据存储组件。它为每个值维护多个具有对称属性和操作的值。当操作设定一个值后,将触发相应的属性。此外,当组件发现它所在的页面变为可见时,它将触发所有已知属性。关键是组件为应用程序的所有实例维护单一的数据模型。也就是说,当置于多个页面时,在某一页面设定的值可以在另一个页面中检索到。

在使用聚合组件时,不能使用普通的方法直接连接组件之间的值。相反,具有上下文重要性的值将从第一个组件的属性连接到聚合程序中的操作,然后再从聚合应用程序中相应的属性连接到目标组件的操作。针对单个页面执行的普通操作都遵循这一过程。对第一个组件作出的属性修改通过聚合程序传播到目标组件。但是在页面转换期间,当目标页面可见时,聚合程序将发布所有已知值。通过这种方法,当连接到聚合程序时,目标页面上的所有目标组件将进行更新。

例如,某个销售应用程序需要跟踪当前公司、潜在客户和销售代表。其中一个页面显示公司细节,以及该公司的销售代表列表。选择销售代表之后,将出现一个弹出式窗口,显示有关该销售代表的详细信息,如电话号码和邮件地址。您可以选择创建新的潜在客户,这将显示复合应用程序中的另一个页面。需要根据当前的设置值预填充公司名称和相关的销售代表字段,但是,仅仅使用跨页面连接无法实现这一目的。

为此,将在第一个页面引入一个聚合组件。负责选择公司和销售人员的组件通过聚合组件确定连接路径。随后将同一聚合组件的另一实例放入第二个页面,将在此页面创建潜在客户。接着,将当前公司和销售人员的属性连接到对应的输入字段中,当聚合组件检测到页面发生切换时,它将触发属性并预填充表单。

其他组件模式

本系列下个月的文章将讨论详细的信息组件、编辑模式组件、摘要组件、列表组件和受限列表组件。尽管本文所述内容针对 Lotus Notes 上下文,但是这些模式可以应用到任何形式的开发环境中。

布局模式

本节将介绍各种布局模式。

Radiating 指示板

复合应用程序可以向正在处理的流程上下文添加相关信息;然而,您仍然要将注意力主要集中在中心工作上。可以使用某种模式来平衡这两种需求,该模式页面中主要活动使用的组件占用中心区域。这些通常是以域为中心的组件,可以查看、操纵和处理单条记录或数据集合。

其他上下文组件布置在屏幕的边缘位置,可显示中心操作的详细信息和上下文。这个指示板位于中心区域的两侧、底部,甚至可位于中心区域的顶部,您可以根据设计需求安排布局。可以将组件组织在文件夹中,从而管理屏幕操作区域并提供丰富、可立即访问的信息,同时不会占用大量空间。同样,可以使用弹出式组件在需要时显示最小化显示的 UI,从而管理空间。

连接 radiating 指示板页面十分简单。通常,建立上下文的位置(例如用户选择、跨页面连接或聚合组件)与主要的域中心组件之间存在数据源连接。这些连接将进一步扩展到指示板,为需要索引的键提供显示的数据。

Lead Manager 应用程序中的一些页面就使用了这种布局,例如 Sales Lead Details 和 Company Details(参见图 1)。占用屏幕中心区域的组件将详细显示目前持有焦点的主要记录。指示板包含了一个附签式文件夹,提供与该记录相关的其他信息集合。

图 1. 公司细节
公司细节
公司细节

在只读模式下单击 Info 按钮将显示弹出式组件(参见图 2)展示更多信息。在编辑模式下,弹出式组件将变为选择组件,协助实现复合。

图 2. 弹出式组件显示公司细节
弹出式组件显示公司细节
弹出式组件显示公司细节

列表页面

列表页面旨在显示某一范围内数据记录的聚合信息。页面中心区域通常由列表或受限列表组件构成,提供各种方法排序或显示数据记录。作为补充,其他信息组件对进行显示和选择的信息摘取共性信息。在 Help Desk 应用程序中,您可以在列表组件中查看特定员工的通话记录,而信息组件可以列出所显示通话的平均通话时间。在财务应用程序中,可以列出某一账户进行的交易,而摘要组件可以列出所浏览交易的总价值。

选择页面

选择页面是列表页面的变体。在列表页面中,查看聚合信息可以全面理解信息集合。在选择页面中,也可以查看聚合信息,然后进一步聚焦特定数据元素。这样,您的 UI 页面可以将您导航到其他区域(例如 radiating 指示板)中显示具体细节的页面。

选择页面通常由一个或多个允许用户选择条件的选择组件构成。受限列表组件根据这些条件查看数据集。受限列表中的选择或焦点状态将进一步投影到信息组件的指示板中,提供更多详细信息并指导作出选择。当选择好要进一步查看细节的数据后,将激活选择,例如,单击按钮或双击鼠标左键可设置上下文或切换到正确的页面。如果上下文比较简单,将通过一个跨页面连接执行;否则,将使用一个聚合组件和一个页面切换组件执行操作。

连接选择页面比连接 radiating 指示板页面稍微复杂一些。选择组件必须连接到受限列表,后者再连接到指示板组件。如果含有多个选择器或多个列表,则可能需要多个并行连接,以确保在激活相应控制后显示正确的数据流。

注意:使用附签式文件夹时需要稍加注意。例如,如果非附签式信息组件连接到附签式受限列表,那么这些列表不仅在选择发生改变时需要传播其选择状态,当选择变为可见时也要执行相同的操作,从而确保信息组件能够正确显示相关内容。

在 Lead Manager 应用程序中,Sales Leads 页面(参见图 3)使用 Selection Page 进行布局。Lead Browser 组件位于屏幕的左侧,可以显示多个选择模式。您可以列出各个公司(根据盈利规模、业务领域等排序并选择)并从特定公司中列出潜在客户。您还可以列出销售人员以及各个销售人员负责的潜在客户。所有这些内容都提供给屏幕右侧的受限列表,根据在 Lead 浏览器中选择配置并确定潜在客户状态,受限列表组件将显示处于待定和关闭状态的潜在客户。

当更新这些组件中的某个选择时,屏幕底部的信息组件将显示所选择的潜在客户及其所属公司的摘要信息。如果双击某个潜在客户,将通过跨页面连接传递该潜在客户的信息并进行页面切换,显示关于该客户的详细信息。

图 3. Sales Leads 页面
Sales Leads 页面
Sales Leads 页面

记录显示页面

该页面显示某个特定记录类型的详细信息。主要显示区域展示目标记录类型的详细信息。在指示板区域,将安排额外的组件来提供与数据记录相关的补充信息。

在 Lead Manager 应用程序中,Company Details 屏幕就按照这种模式布局(参见图 1)。屏幕中心区域显示某条公司记录的完整描述。指示板包含附签式文件夹,其中的组件显示该公司的潜在客户、公司介绍、企业网站等内容。单击 Info 按钮将显示包含更多信息的弹出式组件(参见图 2)。

记录编辑页面

该页面类似于记录显示页面,惟一不同的是可在此编辑目标记录。此时没有必要使用相关数据的指示板,因此此时记录值并不完整或正在创建中。相反,指示板包含的组件用于帮助用户实现记录合成。

例如,您可以使用一个选择组件对企业数据库进行索引,而这个数据库与需要输入员工姓名的字段相绑定;您可以查看最近的邮件以编辑联系人字段;还可以使用 Web 浏览器进行常规搜索,将当前 Web 地址导入到相应字段中。

您可以根据自己的需要,创建既是记录显示页面又是记录编辑页面的页面。这样可以始终以固定格式显示记录细节,但是,如果某些信息组件只与只读或编辑模式相关,那么需要确保正确处理这些组件的启用和可见性。

应用程序模式

本节将讨论应用程序模式。

以数据为中心

以数据为中心的应用程序主要关注所管理的数据。可以通过从涉及的信息域中选择一些主要数据记录进行设计。构建列表页面显示有关数据记录集合的聚合信息。可针对包含的记录类型创建一个记录显示页面,并为可进行创建或编辑的记录类型创建记录编辑页面。这可以组织为一个树形结构,其中列表页面为树干,记录页面为树叶。您可以使用内置的复合应用程序导航器切换页面,使用聚合组件在进行页面转换时保持上下文。通过使用跨页面连接激活页面并建立上下文,可以在导航时隐藏叶页面。

Lead Manager 样例应用程序在设计时主要依据了这一模式。因为可以进入编辑模式,所以您可以以列表(例如选择页面)或个体(例如记录显示页面)形式查看潜在客户、公司、联系人、讨论和合同。对于可以向下展示更多细节的区域,可以进行顶级访问。还提供了交叉链接支持,从而能够从某个详细的上下文移至另一个与之对应的上下文中。在 Lead Manager 样例中,在 Leads/Companies、Discussions、Contracts 和 Contacts 等不同的应用程序域中实现了交叉链接。

以流程为中心

以流程为中心的应用程序侧重于某一任务而非具体的数据。根据面向某一员工角色的工作流场景,您将在应用程序中创建一系列页面,员工可通过这些页面完成分配的任务。例如,在一个管理广告创建的应用程序中,工作流引导您完成从确定目标和定义到寻找代理、管理并批准代理,以及最终完成归档等各个阶段工作。

无论何种情况,您可以具有相同的数据记录集。当确定目标和定义之后,可将广告活动记录链接到讨论区域或活动组,参与者从此处确定广告活动内容。在寻求代理阶段,可以使用一些组件将之前定义的目标提炼为关键字以进行搜索,或者使用字段组件列出关于以前合作的代理的反馈。在管理项目时,可能需要使用邮件数据库跟踪信件往来并管理退出。最后,在归档阶段,需要使用过去活动的合计清单或由这些广告活动产生的效益。

在以流程为中心的应用程序中,您具有一组专门针对当前任务和主要记录的工作流状态的页面。不同角色的员工只能看到与之相关的页面,这可以通过在 WebSphere Portal 部署的应用程序中实现,方法为在复合应用程序的页面中设置权限。这种方法不能用于 NSF 部署的复合应用程序中;因此,最简单的方法是为每个角色创建不同的复合应用程序,其中只包含各个角色所需要的页面。

事实上,复合应用程序的一大优点就是只需执行较少的工作就可实现针对特定区域的不同应用程序。通过重用组件,不必进行大量重复开发和重新部署就可获得生产力得到增强的应用程序。

如当前所定义的一样,Lead Manager 样例使用了以数据为中心的模式。此外,通过重用 Lead Manager 样例中的大量组件,可以创建一个全新的复合应用程序来利用以流程为中心的应用程序模式 —— 例如,管理与合同相关的流程。潜在客户所有者为某一特定潜在客户创建合同之后,法律部门将针对合同进行审查,然后再由用户过目。复合应用程序可以定义这个流程并提供帮助。

聚合模型

聚合应用程序可以将多个流程聚集在一起,但是大多数属于界面集成。它的优点是将用户所需的工具集中到一个位置从而方便工作。这种集成程度较轻,只需少量互操作,但是开发迅速且简单,可以作为用户工具集成的初级阶段。随着了解程度加深,可以使用聚合应用程序将复合应用程序的优势扩展到广泛的用户范围中。

您可以从用户那里获得反馈,了解在哪些位置执行互操作有意义并对流程有帮助,从而进一步细化方法。您可以从封装完整应用程序的单个组件入手,并根据用户需求将这个组件拆分为多个能够在任何位置呈现的更小的组件。

聚合模式最早用于 Lead Manager 样例应用程序的开发阶段。用户与 4 种应用程序进行交互:Leads/Companies、Discussions、Contracts 和 Contacts。通过将独立的 NSF 应用程序集成为单个多页面复合应用程序,您将体会到复合应用程序的优点。

结束语

本文描述的模式仅仅是所有复合应用程序和组件模式的其中一小部分。这些模式可以按照组件、布局和应用程序以及角色分类,可能并不完全适用。最好全面了解所有模式类别,理解其他人如何使用组件和装配应用程序。

在开发 Lead Manager 样例和其他复合应用程序时,我们发现其中很多模式都非常有用。其中一些模式可能看上去十分明显,但是,识别各种开发模式有助于您创建具有一致感官以及依赖经过测试的技术和组件的应用程序。

在研究复合应用程序时,可能会发现可以使用其他方式解决遇到的问题。记录这些方法,寻找成功解决相同问题的其他方法,并开始创建属于您自己的模式库。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus
ArticleID=290100
ArticleTitle=设计复合应用程序:设计模式
publish-date=02182008