在欧洲央行的存档设计模式中，JavaFX FXML控制器属于哪里？

Question

I想知道fxml控制器在实体-控制-边界模型中属于哪里？

在场景生成器的帮助下设计JavaFX应用程序时，场景生成器生成一个表示GUI的fxml文件。此外，还需要一个控制器来使用户交互成为可能。例如: LoginScreenUI.fxml & LoginScreenUIController.java。

我们知道的是：

1. entity对象是一个表示系统数据的对象。
2. boundary对象是一个与系统用户接口的对象。
3. control对象是一个实现管理各种元素及其交互所需的逻辑的对象。它充当中介，即边界对象和实体对象之间的粘合剂。

我发现的所有解释都是基于与MVC模型的比较，以下是一些：

• 实体-控制-边界模式(ECB)是模型-视图-控制器模式的一个变种.从Mapping到MVC:我们可以将填充实体的内六角映射到模型-视图-控制器模式中的模型角色。控制器显然映射到控制器，边界(至少是与用户交互的边界)映射到视图。

• 它们并不相似。MVC是用于用户交互的。业务规则不直接绑定到用户，甚至不绑定到I/O设备，比如互联网本身。欧洲央行模式用于将业务实体与边界分离(mvc框架，ORM的)。

我认为自己同意这样的解释，即欧洲央行模式是一种类似于MVC模式的模式，当涉及到更多类似于客户机-服务器的体系结构时。因此，在实现每一种方法时都会出现一些差异。

不过，我并不完全满意，因为我找不到任何直接的答案来回答我的问题，而且问题仍可供个人解释，而不是有明确的指引。

更具体的是，当用户输入ID、密码&单击Login按钮时。我的控制器处理那个按钮点击。有两种可能的情况:假设

1. 假设我的控制器属于控制类别。我可以马上检查用户是否通过执行查询在我的数据库中注册。
2. 假设我的控制器属于边界类别。我得再找一个“中间人”来验证证件。

我不能在错误的假设基础上前进，这将大大减缓未来的发展，并引入许多需要痛苦纠正的错误。任何帮助都将不胜感激。

谢谢。

Answer 1

实体-控制-边界是一种架构模式，其目的是在用例和代码之间建立链接。

欧洲央行的

体系结构与MVC

的比较

欧洲央行与MVC有一些相似之处。例如，欧洲央行实体与MVC模型之间的有一个直截了当的关系，以及MVC视图与欧洲央行边界之间的C3.但欧洲央行-控制和MVC-控制之间有很大的区别：

• 在原始MVC中，控制器是用户接口的一部分，也就是说控制器处理用户的输入(而视图处理输出)。根据这个逻辑，任何业务逻辑都不应该在控制器中，而应该在模型中。
• 在欧洲央行，该控件实现一个用例，这意味着它协调与边界和实体的交互，但也确保事务业务逻辑。

这意味着，如果你想用MVC来映射欧洲央行控制，你首先必须重新了解你的欧洲央行控制，把它分成两部分：

• 一方面，事务逻辑和与实体的交互(MVC-M)，如果使用Martin的术语，这将类似于事务性脚本；
• 另一方面，与边界的交互(MVC-C)

，但您的体系结构目标是什么?

问题不在于建筑应该是什么，也不在于如何把正方形挤进圆圈。问题更多的是你想让它变成什么样。你想要MVC，MVVM，MVP还是欧洲央行的架构？为什么呢？

您的控制器的目标显然是处理用户事件(“我的控制器处理该按钮单击”)。因此它属于欧洲央行--边界。如果你想采用欧洲央行，你应该确保一个真正的分离关注。因此，您的控制器应该与处理应用程序逻辑(这里是连接)的另一个对象进行交互，而不依赖于用户界面。所以你的第二选择就是走下去。

当然，这可能是一种开销。这取决于你是否值得付出额外的努力。特别是如果你的应用程序是一个前端，而真正的应用程序逻辑被很好地封装在后端的话。

但是，如果你采用这样的结构，它也有优势：

• 有一天，您可以决定用另一种技术代替JFX :只有边界必须改变(这符合六角形建筑的精神)。
• 您可以更容易地测试业务逻辑，方法是让测试用例直接调用贯穿UI的业务逻辑。
• 你总有一天可以用SSO登录代替你的密码登录，等等.

希望这能有所帮助。