我试图了解如何将类分类为边界/控制/实体类。我可以理解边界和实体类，尽管我的理解可能并不完美。边界是与用户交互的类。所以用于用户界面的类将是边界类。实体类处理数据。所以我在 ER 图中使用的实体将是实体类。但我不明白为什么要使用控制对象。据说控制对象是用来封装领域功能的。如果不使用控制类怎么办。你能用例子解释一下吗？我找到了一些解释，但我仍然很困惑。为什么边界不应该直接与实体交互？还有一些不是边界/控制/实体的类。它们是什么？
【问题讨论】：
标签： uml class-diagram ecb-pattern
背景
Entity/Boundary/Control 方法是由Ivar Jacobson 在 1992 年作为其用例驱动的 Objectory 开发方法的一部分引入的。
当时 Jacobson 使用术语实体/接口/控制。在 1992 年和 1994 年，你可以在 ECB 中找到奇怪的循环符号，在他的书中已经使用了。顺便说一下，当 Rational 收购时，他的方法的用例被集成到 UML 中，他的开发过程被合并到 RUP 中反对。
他的方法背后的想法是采用一种非常逻辑和形式化和演绎的分析和设计方法。它从用用例识别系统行为需求开始。然后，用例到外部世界的每个链接都将表示为一个接口对象，负责完全封装用户界面。
每个用例将表示为一个或多个控制对象：
控制对象：封装一个或一个功能的对象 几个用例 - I.Jacobson in The Object Advantage，ACM Press，1994
最后，系统管理的业务对象可以从用例和分析过程中部分推断出来。
其他信息
Iconix process 的基础是在 1999 年作为 Rosenberg 和 Stephen 所著的“使用 UML 的用例驱动对象建模”一书的一部分介绍的。引入了一些额外的robustness constraints，当然是为了改进关注点的分离。例如，实体与边界之间的直接联系是被禁止的。一切都必须通过控制对象进行引导：
控制对象（我们通常称之为控制器，因为它们经常 不是真实的对象），充当边界对象之间的“粘合剂”和 实体对象 - D.Rosenberg，在链接的 DDJ 文章中。
他们添加了一条建议来澄清意图：
边界对象和实体对象都是名词，控制器 是动词。
结论
所以原则是控制对象代表用例提供的业务逻辑，一方面与边界交互，另一方面与实体交互。控制对象不能被外界直接调用/访问。
如果您想避免控制对象，您将拥有一个边界对象，其方法对应于您的系统应该提供的动词/功能/用例。这不会根据现代欧洲央行，但根据雅各布森的原始方法完全有效。尽管如此，您的边界将不再符合SOLID 设计的single responsibility principle。
【讨论】：
边界与参与者（例如用户）交互。
实体类代表数据。
控制在边界和实体之间进行调解（例如，对实体执行操作）
来源：http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
【讨论】：
控制类包含业务逻辑。它是系统中最重要的部分。虽然边界只控制文本是绿色还是蓝色（非常基本），而实体控制数据是否存储在文本文件或数据库中（也非常基本），控制类执行所有业务逻辑。当边界发送鼠标/键盘事件时实体中发生的变化，反之亦然，边界中的实体显示什么。
【讨论】：