控件类有什么用？

Question

我试图理解如何将类分类为边界/控制/实体类。我可以理解边界和实体类，虽然我的理解可能不完美。边界是与用户交互的类。因此，用于用户界面的类将是边界类。实体类处理数据。因此，我在ER图中使用的实体将是实体类。但我不明白为什么使用控制对象。据说控制对象用于封装域功能。如果不使用控件类怎么办？你能用例子解释我吗。我找到了一些解释但我仍然感到困惑。为什么边界不应该直接与实体互动？还有一些不是边界/控制/实体的类。它们是什么？

Answer 1

背景

实体/边界/控制方法由Ivar Jacobson于1992年引入，作为其用例驱动的Objectory开发方法的一部分。

当时雅各布森使用术语实体/接口/控制。您可以在1992年和1994年的书中使用与ECB相关的奇怪圆符号。顺便说一句，他的方法的用例被集成到UML中，当Rational获得时，他的开发过程被合并到RUP中。对象工厂。

他的方法背后的想法是采用一种非常逻辑，正式和演绎的分析和设计方法。首先是用用例来识别系统行为要求。然后将用例的每个链接表示为外部世界的链接对象，该接口对象负责完全封装用户界面。

每个用例都表示为一个或多个控件对象：

  

控制对象：封装一个或多个功能的对象   几个用例 - I.Jacobson在对象优势，ACM出版社，1994

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

其他信息

Iconix process的基础是1999年引入的，作为Rosenberg＆amp; Sons出版的“使用UML 的用例驱动对象建模”一书的一部分。斯蒂芬。引入了一些额外的robustness constraints，当然是为了改善关注点的分离。例如，禁止实体和边界之间的直接链接。一切都必须通过控制对象引导：

  

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

他们添加了一个澄清意图的建议：

  

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

<强>结论

因此，原则是控制对象代表用例提供的业务逻辑，一方与边界交互，另一方与实体交互。外部世界不能直接调用/访问控制对象。

如果你想避开控制对象，你会得到一个边界对象，其方法对应于你的系统应该提供的动词/函数/用例。这不符合现代欧洲央行，但根据雅各布森的原始方法完全有效。然而，您的边界将不再符合single responsibility principle设计的SOLID。

Answer 2

• 边界与演员（例如用户）互动。

• 实体类代表数据。

• 控制介于边界和实体之间（例如，对实体执行操作）

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

Answer 3

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