3

我试图了解如何将类分类为边界/控制/实体类。我可以理解边界和实体类，尽管我的理解可能并不完美。边界是与用户交互的类。所以用于用户界面的类将是边界类。实体类处理数据。所以我在 ER 图中使用的实体将是实体类。但我不明白为什么要使用控制对象。据说控制对象是用来封装领域功能的。如果不使用控制类怎么办。你能用例子解释一下吗？我找到了一些解释，但我还是很困惑。为什么边界不应该直接与实体交互？还有一些不是边界/控制/实体的类。这些是什么？

4

3 回答 3

1

背景

Ivar Jacobson在 1992年引入了实体/边界/控制方法，作为他的用例驱动的对象开发方法的一部分。

当时 Jacobson 使用了术语实体/接口/控制。在 1992 年和 1994 年，你可以在 ECB 中找到奇怪的循环符号，在他的书中已经使用了。顺便说一下，当 Rational 收购时，他的方法的用例被集成到 UML 中，他的开发过程被合并到 RUP 中反对。

他的方法背后的想法是采用一种非常逻辑和形式化和演绎的分析和设计方法。它从用用例识别系统行为需求开始。然后，用例到外部世界的每个链接都将表示为一个接口对象，负责完全封装用户界面。

每个用例将表示为一个或多个控制对象：

控制对象：封装一个或多个用例功能的对象 - I.Jacobson 在The Object Advantage中，ACM Press，1994

最后，系统管理的业务对象可以部分地从用例和分析中推断出来。

附加信息

Iconix 过程的基础是在 1999 年作为Rosenberg 和 Stephen所著的“使用 UML 的用例驱动对象建模”一书的一部分引入的。引入了一些额外的健壮性约束，当然是为了改进关注点的分离。例如，实体与边界之间的直接联系是被禁止的。一切都必须通过控制对象进行引导：

控制对象（我们通常称为控制器，因为它们通常不是真实对象）充当边界对象和实体对象之间的“粘合剂” - D.Rosenberg，在链接的 DDJ 文章中。

他们添加了一项建议以澄清意图：

边界对象和实体对象都是名词，控制器是动词。

结论

所以原理是控制对象代表用例提供的业务逻辑，一方面与边界交互，另一方面与实体交互。控制对象不能被外界直接调用/访问。

如果您想避免控制对象，您将拥有一个边界对象，其方法对应于您的系统应该提供的动词/功能/用例。这不会根据现代欧洲央行，但根据雅各布森的原始方法完全有效。然而，您的边界将不再符合SOLID设计 的单一责任原则。

于 2016-07-21T23:47:53.737 回答
0

控制类包含业务逻辑。它是一个系统中最重要的部分。虽然边界只控制文本是绿色还是蓝色（非常基本），而实体控制数据是否存储在文本文件或数据库中（也非常基本），控制类执行所有业务逻辑。当边界发送鼠标/键盘事件时实体中的更改内容，反之亦然边界中的实体显示的内容。

于 2016-07-21T08:24:46.437 回答
0

  • 边界与参与者（例如用户）交互。

  • 实体类表示数据。

  • 控制在边界和实体之间进行调解（例如对实体执行操作）

资料来源：http ://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm

于 2016-07-21T03:30:15.203 回答