Windchill 建模启发法
本节旨在介绍有关 Windchill 类体系结构设计的背景以及在建模中使用的方法。Windchill 类体系结构旨在实现以下目标:
推动可反映三层体系结构特征的业务对象的开发;即,客户端层的表示、服务器层的业务逻辑以及数据库层的持续性。
确定生成优化代码时可基于的模型。应提供生成的代码以管理对象的状态、在客户端与服务器之间传输对象以及处理数据库中的对象。
提供支持增值开发的环境。必须能够扩展模型并将新功能放入现有对象中。
要实现这些目标,一种方法是继承功能。
通过继承获得的功能
将子类添加到父类时 (在这种情况下,依次使用 Item 和 DomainItem 扩展类 WTObject),则子类将继承先前的每个类的属性和方法。此方法适用于很多情况。但有时,您只需一小部分的继承功能。在这种情况下,要么对象中的功能远远多于实际所需,要么您仅复制所需代码并将其添加到您自己的对象中,从而造成冗余和潜在的维护问题。
另一种方法 (已在 Windchill 中实现) 是将如下图所示的功能划分为主要用于维护业务信息的对象 (也称为 knower),以及主要用于执行业务操作的对象 (也称为 doer)。
通过划分获得的功能
使用此方法时,业务模型具有两种主要类型的类:业务信息类和业务管理器类。
业务信息类表示要在数据库中管理和维护的业务信息和关联。这些类用于扩展 Windchill 中提供的基础类。它们可以实现一个或多个业务管理器接口。这些类会在客户端和服务器之间随数据往复传送。
业务管理器类表示应用于业务信息对象的业务规则。这些类用于扩展 Windchill StandardManager 类。业务管理器会实现一个接口类,用于为业务管理器方法提供客户端 API。业务管理器类的代码位于服务器中。
下面是 Windchill 提供的管理器之一 LockService 的示例。(在命名类中,管理器有时也称为服务。)
LockService 示例
在此示例中,可锁定对象是由 MyItem (同时扩展抽象类项) 实现的 "knower"。可锁定对象 (包括 MyItem) 由 StandardLockService ("doer") 管理,其中 API 由实现的远程接口 LockService 呈现。
除了从 Item 继承的属性和方法外,MyItem 还具有在 Lockable 接口中定义的功能。
图左侧显示了如何在客户端上对服务器端服务的接口进行建模。doer 是 StandardLockService,且在服务器上运行。它继承自 Windchill StandardManager,后者为典型管理器提供标准的基本操作,例如启动和关闭。(自行编写管理器时,它们也可以继承自 StandardManager。)
LockService 接口用于描述客户端上提供的锁定服务,即锁定和解锁。这些服务将从客户端远程调用到服务器。服务器上的 StandardLockService 实际上包含支持锁定和解锁方法的所有代码。
LockService 的 API 需要一个可锁定对象。它们可以接受 MyItem,因为 MyItem 已实现 Lockable 接口。同样,它们也可以接受实现 Lockable 接口的任何其他业务信息类。要获得对锁定服务功能的访问权限,必须针对类实现 Lockable 接口。
这对您有帮助吗?