在我的课堂上，我们一直在学习不同的设计，例如 MVC 和 MVP。我目前正在编写一个在 JTable 和自定义绘图中显示数据的应用程序。我的问题是我应该如何在视图和控制器之间进行通信。
例如，我有一个按钮，可以将文件中的数据导入模型。我想我想要的是通知控制器用户想要导入文件的视图。然后控制器执行必要的逻辑来执行此操作。视图应该如何做到这一点？我看到了几个选项。 1）让控制器创建一个内部类，每当用户点击导入按钮时都会调用该内部类。在这种情况下，控制器必须调用视图的方法来查看用户想要导入的文件。 2) 让视图检测到事件，然后在控制器中调用适当的方法并传递文件名。
这引出了一个更大的问题，即视图是否知道控制器？我知道这些事情没有正确答案，但最好的方法是什么？
【问题讨论】：
标签： java model-view-controller view controller communication
我通常将 Views 设为 Controller 的 Listeners。通过这种方式，我可以拥有同一个控制器的几个不同的视图。所有视图都应该实现一些通用接口。我使用构造函数注入提供从 View 到 Controller 的访问。所以可以smt这样
InterfaceWithMethodThatViewCanCall controller = new ConcreteController(new Model);
SomeView view = new ConcreteSomeView(controller);
controller.addListener(view);
我目前尝试使用的另一种方式是通信抛出 EventBus。我建议您锁定 GWT 哪些 MVP 使用示例。
*很遗憾，我还没有阅读任何关于该主题的优秀研究出版物。
【讨论】：
无论如何，视图必须知道控制器。根据我的经验，由 GUI 生成的事件（例如按钮单击、拖放等）最好在视图本身中处理，因为它们特定于您正在使用的视图类型（如果您的例如，用户界面是基于语音的）。控制器应该公开 API，如
importFile(String filePath)
使用您的 1) 方法，每当您添加新视图/更改视图中的内容时，您都必须修改控制器。 2) 方法更好。
【讨论】：
您可能知道，控制器层在大多数情况下与视图层紧密耦合。
在我作为架构师或程序员参与的项目中，我从未将业务逻辑放在控制器中。因为我从未见过可以移植直接与视图通信的层的任何技术。
控制器层应该充当视图的服务层。所以是的。视图必须知道控制器。而且，如果前面的陈述是正确的，那么控制器可以与视图通信就没有问题了。
我在完全基于 POJO 的层中设计我的业务逻辑（我的 @EJB 或 spring 的 @Service）。那是我的可移植业务层。
控制器只是视图和业务规则层之间的桥梁。它调用业务方法，正确格式化它们的响应（有时）并发送回视图。在这种情况下，控制器可以是 Web 服务、托管 bean、测试套件等......
【讨论】：