MVC视图和控制器通信的实现。 （爪哇）
在我的课堂上，我们一直在学习不同的设计，例如 MVC 和 MVP。我目前正在编写一个在 JTable 和自定义绘图中显示数据的应用程序。我的问题是我应该如何在视图和控制器之间进行通信。
例如，我有一个按钮，可以将文件中的数据导入到模型中。我想我想要的是视图通知控制器用户想要导入文件。然后控制器执行必要的逻辑来执行此操作。视图应该如何做到这一点？我看到有几个选择。 1) 让控制器创建一个内部类，每当用户点击导入按钮时就会调用该内部类。在这种情况下，控制器必须调用视图的方法来查看用户想要导入的文件。 2) 让视图检测事件，然后调用控制器中的适当方法并传递文件名。
这就引出了一个更大的问题：视图是否知道控制器？我知道这些事情没有正确的答案，但最好的方法是什么？
In my class we have been learning about different designs such as MVC and MVP. I am currently writing an application that displays data in a JTable and a custom plot. My question is how should I go about communicating between the View and Controller.
As an example, I have a button that should import data from a file into the Model. What I think I want is the View to notify the controller that the user wants to import a file. The controller then does the necessary logic to do so. How should the view do so? I see a couple of options.
1) Have the controller create an innerclass that gets called whenever a user hits the import button. In this case the controller would have to call a method of the view to see what file the user wanted to import.
2) Have the view detect the event and then call an appropriate method in the controller passing with it the name of the file.
This begs the bigger question of whether or not the view knows about the controller? I know there isn't a correct answer to these things but what would be the best way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能知道，大多数时候，控制器层与视图层紧密耦合。
在我作为架构师或程序员参与的项目中，我从未将业务逻辑放入控制器中。因为我从未见过任何技术可以移植直接与视图通信的层。
控制器层应该充当视图的服务层。所以是的。视图必须了解控制器。而且，如果前面的陈述为真，则控制器与视图通信就没有问题。
我在完全基于 POJO 的层中设计我的业务逻辑（我的 @EJB 或 spring 的 @Service）。这是我的便携式业务层。
控制器只是视图和业务规则层之间的桥梁。它调用业务方法，正确格式化它们的响应（有时）并发送回视图。在这种情况下，控制器可以是 Web 服务、托管 Bean、测试套件等......
As you may know, the Controller layer is, most of the time, tightly coupled to the View layer.
In the projects I participate as a architect or programmer, I never put business logic in a controller. Because I never saw any technology in which the layer that communicates directly to the view can be ported.
The controller layer should act as a service layer to the view. So yes. The view must know about the controller. And, if the previous statement is true, there's no problem the controller could communicate with the view.
I design my business logics (my @EJB or spring's @Service) in a completely POJO-based layer. That's my portable business layer.
The controller is just a bridge between the view and the business rules layer. It calls business methods, format their responses properly (sometimes) and send back to the view. In this context, the controller can be a web service, a managed bean, a test suite, etc...
不管怎样，视图必须了解控制器。根据我的经验，GUI 生成的事件（例如按钮单击、拖放等）最好在视图本身中处理，因为它们特定于您正在使用的视图类型（如果您的视图类型不同，则会有很大不同）例如，UI 是基于语音的）。控制器应该像 1) 方法一样公开 API
，每当添加新视图/更改视图中的内容时，都必须修改控制器。 2）方法更好。
One way or the other, the view has to know about the controller. In my experience, events generated by GUI (such as button clicks, drag-and-drops etc.) are best handled in the view itself, since they're particular to the type of view you're using (would differ significantly if your UI was voice-based, for example). Controller should expose APIs like
with your 1) approach, you'd have to modify the controller whenever you add a new view / change things around in the view. 2) approach is better.
我通常将视图作为控制器的监听器。通过这种方式，我可以对同一个控制器拥有多个不同的视图。所有视图都应该实现一些通用接口。我使用构造函数注入提供从View到Controller的访问。所以可以像这样smt
我目前尝试使用的另一种方式是通信抛出EventBus。我建议您锁定GWT哪些 MVP 使用示例。
*不幸的是，我还没有读过任何关于这个主题的好的研究出版物。
I usually, make Views as Listeners of Controller. In this way I can have several different views of same controller. All views should implement some common interface. I provide access from View to Controller using constructor injection. So it can be smt like this
Another way that I currently try to use is communication throw EventBus. I would recommend you to lock at GWT which MVP usage examples.
*Unfortunately I haven't read any good research publication on this topic.
您可以创建将由视图调用并由控制器侦听的主题。这样视图就不会知道控制器，它基本上会通过主题与控制器进行通信。
在您的示例中，您将拥有 fileImportedSubject ，控制器将监听该文件，并且在每次发射时它都会相应地更改模型。
因此，这是两者之间的一种巧妙的沟通方式，但除了一些简单的应用程序之外，我不会推荐它用于任何其他用途。因为在某些时候，您将创建太多控制器需要监听的主题，此时我认为这种方法开始代表糟糕的设计。
You could potentially create Subjects which will be called by view and listened to by controller. That way view wouldn't know about controller, it would basically communicate with controller via Subjects.
In your example you would have fileImportedSubject and controller would listen to that, and on each emission it would change model accordingly.
So this is a neat way of communication between those two, but i would not recomend it for anything other that some simple apps. Because at some point you will create too many Subjects that controllers need to listen to, and at that point i think that this approach start to represent bad design.