Implementation of MVC View and Controller communication. (Java)_问答_开发者

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 vie开发者_Go百科w 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?

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...

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

importFile(String filePath)

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.

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

InterfaceWithMethodThatViewCanCall controller = new ConcreteController(new Model);
SomeView view = new ConcreteSomeView(controller);
controller.addListener(view);

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.

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.