逻辑模型：应用程序定义和规划
COM+ 应用程序设计过程的第二步是将概念模型分解为三层体系结构的逻辑层：呈现层或用户服务；中间层或业务服务；以及数据层或数据服务。 如果不熟悉三层体系结构，请参阅使用三层体系结构模型。
通过浏览名词和谓词的概念模型来开始此过程。 名词通常可以转换为业务对象（类），与之关联的谓词可以转换为操作（类的方法）。 尽管很难将所有名词定义为业务对象，但完成逻辑模型时，遗漏或错误将变得显而易见。
大多数业务对象最终将位于业务服务层，其余对象可划分为用户服务层中的用户界面对象与数据服务层中的数据对象。 使用三层体系结构创建逻辑模型时，请记住以下几点：
- 概念设计中的一些名词不会表示实际的物理数据片段，但可能表示系统上的操作或系统上的业务对象角色。 业务对象也可以是执行某种系统控制的服务，例如用于实现安全性的登录 ID。
- 通过在概念模型中“在行之间读取”，避免创建模糊的业务对象。 此类业务对象可能不正确，在逻辑模型中包括这些对象之前应仔细考虑。 如果它们看起来正确，请显式将其添加到概念模型。
- 避免创建表示相同信息或函数的业务对象；在应用程序速度和性能方面，重复可能会成本高昂。
- 确定对象依赖项。 概念模型中的某些名词可能只是其他业务对象的属性。 确定属性是否可以独立存在。 如果可以，它应成为自己的业务对象；如果不能，则应将其与相应的业务对象组合。
- 避免创建会尝试执行太多操作的业务对象。 业务对象过载可能意味着以后在分离代码时花费的时间更多，并且可能会带来维护问题。 不应组合概念模型中的不同对象；它们应保留为单独的业务对象。 可以使用代码将其公共函数委托给业务对象，以便处理任何相似之处。
- 删除任何在任何使用方案中都未使用的任何业务对象。 如果对象旨在适应未来的增长，请考虑在完成初始应用程序后实现这些对象。
此时，可以开始考虑计算机和代码。 从这些业务服务中，确定需要作为用户服务提供的显示和输入功能。 定义需要作为数据服务提供哪些表和存储过程。 若要完成逻辑模型，请为每个服务定义接口，并包括每个数据字段的定义及其验证规则。 此外，包括所有函数、其语法及其参数。
服务或对象定义不应包括物理实现的任何方面。 目的是为逻辑组件生成器提供明确的指南，让其他程序员能够在实际完成之前编写可能使用该组件的应用程序的片段。 在逻辑模型设计中，应记录每个屏幕、函数和对象。 在满足这些条件之前，请勿继续执行物理模型或实现。 如果在概念模型和逻辑模型未达成一致时继续操作，则在开发周期的后面将遇到严重问题。
COM+ 应用程序的增量开发很常见。 这涉及创建最终的已知组件子集，并通过应用程序的每一层（客户端层、业务层和数据层）测试这些组件，直至数据存储。 此工作模型可用于深入了解客户的其他要求和实现注意事项。 通常，在单个计算机上测试此工作模型。
相关主题