Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In the MVP pattern, there is no dependency between the view and the model. Everything is done by the presenter.
In our GWT-project, we implement all our MVP classes like shown on the GWT .page. To access the view, our presenter uses an interface like this:
public interface Display {
HasClickHandlers getAddButton();
HasClickHandlers getDeleteButton();
...
}
So, the presenter gets a button from the view, and applies its click handlers to it.
But this feels so wrong to me. This violates the single responsibility principle, as well as the information hiding principle. the presenter should not know anything of the internals of the view (even when we get an abstract HasClickHandlers).
In my opinion, we should better use this kind of pattern:
public interface Display {
void setPresenter(Presenter p);
}
public interface Presenter {
void onAdd();
void onDelete();
}
So, the view tells the presenter actively, that some interaction occured. But not on which view-element.
My team partners argue, that with the first solution, we avoid circular dependencies. That´s right. But anyway, I would prefer the second way because the modules are better separated and can be maintained independently.
What are the advantages / disadvantages?
Strongly agree - and the article you link describes both sides, if you continue to the second section.
I don't build my Views exposing widgets or their HasSomethingHandlers - I find it generally better to build the Presenter API to expose those possible interactions for several reasons:
Unit tests - It is simpler to make a mock view which invokes methods rather than firing events. This is not to say that it isn't possible (especially if your Presenter can run on the JVM and you can create a Proxy type for each one.
Cleaning up unused handlers - Presenters are generally cheap and get re-created each time, but sometimes Views are heavy and are saved, reused. Any time you reuse a view, you have to be sure that all of those externally added handlers were removed. This can be done correctly with some "lifecycle" methods like onStop() or something on the presenter, so that whatever code replaces presenters can shut it down, but would need to be factored in.
Multiple view implementations - like unit tests, different view implementations (mobile vs desktop, readonly vs readwrite, etc) might have different ways of causing the same change. Now, you could have multiple methods exposing HasClickHandlers onAddClicked() and HasTouchHandlers onAddTapped(), or, take the approach you describe. (You also can end up leaking some UX details into the presenter, like hitting the Enter key while in the last field, as opposed to clicking the button - that arguably belongs in the view, and not in the presenter).
One downside of this approach: the view needs more brains, and part of the goal of MVP is to keep the view as skinny as possible.
Finally, while this alternative approach isn't actually compared and contrasted on the page you linked, page two of the same article you linked does show your approach instead http://www.gwtproject.org/articles/mvp-architecture-2.html:
Now that we have the UI constructed, we need to hook up the associated UI events, namely Add/Delete button clicks, and interaction with the contact list FlexTable. This is where we’ll start to notice significant changes in the overall layout of our application design. Mainly due to the fact that we want to link methods within the view to UI interactions via the UiHandler annotation. The first major change is that we want our ContactsPresenter to implement a Presenter interface that allows our ContactsView to callback into the presenter when it receives a click, select or other event. The Presenter interface defines the following:
public interface Presenter<T> {
void onAddButtonClicked();
void onDeleteButtonClicked();
void onItemClicked(T clickedItem);
void onItemSelected(T selectedItem);
}
This is done in the context of describing the UiBinder way of building views, but it applies equally well without UiBinder.
So when discussing the article in relation to organizing how your team is building their application, be sure to consider the entire set of articles - those articles are both referenced from http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html, which also assumes this non-eventhandler approach. And in that article there are other "wrong" ways of doing things, like manual dependency injection, instead of an automated reliable tool like Gin or Dagger2.
The articles aren't meant to describe the One True Way, but to understand the ideas and patterns that can be used. Don't cargo cult this, applying patterns blindly, but make sure to understand the pros and cons - and work as a team, a pattern used inconsistently is arguably worse than no pattern at all!
EDIT: I realized I didn't mention the circular dependency issue!
This is as much or as little of an issue as you want it to be. If you create them at the same time, and pass references to the other in the constructors, obviously you have an issue - GWT can't proxy them (and arguably that's a bad idea anyway). But, down the road, you might get into a situation where views are expensive to build and could be pooled/cached and not re-created every time, in which case the view needs to be informed of the new presenter it now works with anyway.
That then requires that the View interface supports a void setPresenter(P) method anyway, so our circle is broken. Keep in mind also that this approach will require either the presenter being sure to clear out data in the view, or the view knowing when a new presenter is set to clear its own data.
My personal approach for this leads to the presenter owning a view field, injected (probably via constructor) when it is created, and have a start method in the presenter. When called, the presenter takes control of the view, and when ready, appends it where it belongs in the dom hierarchy.
Yes, this requires one extra method in the view, but if you have any base class for your views, this will be trivial, and if you end up doing any view reuse, you need that method anyway.
Related
I have tried to adhere to the mvc pattern in the java code that I have written. I want to keep the view and model independant of the controller and from each other. I am also trying my best to use interfaces to keep things modular.
My view has JButtons that I want to "bind" to specific methods in the model through the controller. I have tried two approaches to still keep the view independent of controller:
Registered the controller as an ActionListener to the view-object. Pros: The void addListener(ActionListener listener) abstract method encapsulates this behaviour in the view interface, so more buttons can be added without changing the interface. It also decouples the controller from the view, since it does not know anything about the actual buttons in the view. It is also easier to add more views or more controllers, so it follows the open-closed principle well. Con: For the controller to know the nature of the ActionEvent, I have only been able to come up with using the ActionEvent.getActionCommaned() in a switch statement, so mapping each case to its' corresponding method in the model. This seem unsafe and prone to cause irritation, since it seems like bad practice to match strings like this.
I also came up with adding public addActionListener(ActionListener) methods for each button in the view, like addGasButtonListener(ActionListener). Then doing something like view.addGasListener(e -> model.gasVehicles(view.getGasAmount())) in the controller. Pro: This seems like it reduces the uncertainty of matching strings. Cons: It means I have to add these new methods to the view interface, and each time a new button is added I have to do the same, making it difficult to add new views that does not have anything to do with some of the methods.
Main question:
I prefer the first method since it seems better to me, but I still would like to find a way to avoid matching strings, and find some nice way to do it (more similar to the rigidity of the second way of binding buttons to methdods). Is there?
Follow-up (less important) question:
I should also mention that my controller contains an inner class TimerListener implements ActionListener, that contains the loop of the app that acts on ActionEvents from the Timer. It also acts on ActionEvents from buttons if approach number one is used, which is why my follow-up question is: how would I seperate this main loop that only cares about the timer, from the switch statement used to act on button events. Since the ActionEvent.getActionCommand() is null almost all the time, it would be nice to seperate the two. Is there a approach that would let me do that?
I don't really see the value of working with ActionListener instances in the first place.
From your own example:
view.addGasListener(e -> model.gasVehicles(view.getGasAmount()))
You don't do anything with the actual event
In case you decide to use a different UI element in the future that doesn't fire ActionEvents, you will have to change the type of the listener.
I would rather expose a custom listener/callback that the controller (or model) can register on the view:
void onGasAmountChange(double gasAmount);
That being said, you might be focusing too hard on having a model, view and controller. If you look at more complicated Swing components (JList, JTable, ...), they have a view component and a model (ListModel and TableModel).
You could do something similar and create your own model for your view, and let the view call the necessary methods on the model directly (just like it happens for those Swing components).
That avoids having to write a bunch of one-liner listeners that basically delegate to the model.
In my program the controller just hooks keypresses with a function.
So should ikeep a reference to it?
E.g.
keeping a reference
Model model = new Model();
View view = new View(model);
Controller controller = new Controller(model,view);
or no
Model model = new Model();
View view = new View(model);
new Controller(model,view);
Inside Controller
public Controller(Model model, View view)
{
this.model = model;
this.view = view;
view.setOnKeyPressed(this::doSomething);
}
public void doSomething(KeyEvent event)
{
System.out.println("key pressed");
}
Maybe I implemented the Controller class wrong and misunderstood mvc pattern. But with what i wrote so far there is no reason for me to keep a reference to the controller object.
I'm not sure this question is really answerable, as it is probably too broad and/or too opinion-based. However...
MVC is a very loosely defined pattern. It really goes back about 40 years (or more) to the very early days of research into GUI development at Xerox PARC. Since it's been around so long and its primary use case (GUI architecture) has evolved significantly, it has branched into a number of sub-patterns and variations. Consequently, you'll find that "MVC" means many different things to different developers. In particular, MVC in a web application environment is somewhat different (imo) to MVC in the context you are talking about, because in a web application environment it has to sit on top of the request-response cycle. The rest of this answer/discussion focuses on the original "thick client" version of MVC, in which the view and controller are both in memory within the same process,and can communicate directly (rather than via a request-response protocol such as HTTP).
For me, the definitive guide to MVC in a desktop GUI context is Martin Fowler's essay on GUI architectures.
I would say that "classical" MVC is characterized by:
Having three components:
A model, which provides access to the data, may provide mechanisms for registering listeners for notification of changes to the data, and has no knowledge of the presentation of the data
A view, which observes the data in the model and updates itself when the data changes (this distinguishes classical MVC from some forms of MVP)
A controller, which provides the "view logic": typically this means it responds to user input and updates the model (not the view) as a result
So the model should know nothing at all about the view and the controller. The view doesn't know anything about the controller, but needs a reference to the model so it can display the data, and observe the data for changes, updating the presentation accordingly. The controller also needs a reference to the model, so it can update the data according to user input. Usually, the controller also needs a reference to the view, as it typically needs to register event handlers with the widgets in the view in order to know about user input it has to process.
The driving force behind this design is to allow multiple presentations (think of presentations as a combination of a view and controller) of the data which are kept synchronized. The pattern achieves this by referring everything though the model: one presentation's controller might update the model; since all the views observe the model, they all see those changes and each responsible for updating themselves accordingly. The controller that changed the view does not need to know about any other views that may be observing the data in order to keep all views in sync.
Your application itself will certainly need access to the model; it probably needs to access the data, maybe modify it from external (i.e. not user-driven) factors, persist the data at shutdown, etc. Your application probably needs access to the view (it needs to display it somewhere, may need to dispose of it at shutdown, etc). Your application may or may not need access to the controller. In its purest form, once the controller knows how to observe the view for user events, and knows how to update the model, you never need to communicate with it again. (If you want to change states from "external" events, you do so through the model, not through the controller(s).)
Several variations of this idea have emerged (see Fowler). One popular one (which also have several variations of its own) is Model-View-Presenter. In this variation, the controller is replaced by a "Presenter" which takes on some, or even all, of the responsibility of updating the view. In one form of this (which Fowler calls "Passive View"), the view is completely free of logic and merely lays out the controls. The presenter processes user input, updating the view and the model when user input occurs on the view, and observes the model, updating the view if it changes. This variant has advantages in terms of testability and ability to debug, but there is arguably tighter coupling between the view and presenter than there is between the view and controller. (It is relatively easy to provide multiple controllers for a view; providing multiple presenters for a passive view gets much more complex, and the presenters usually have to have some knowledge of each other.)
JavaFX actually provides "out-of-the-box" support for this style of architecture, using FXML as a (usually passive) view, and providing convenient ways to hook into what it calls the controller (which is perhaps more of a presenter). JavaFX properties make it easy to write models which can readily be observed by a view or by a presenter as needed.
In practice, you'll usually find a hybrid of these works best in most cases. A medium-large scale application will use MVC/MVP-type patterns in multiple places, on multiple different scales. You will often find that it is convenient for the controllers/presenters to have some knowledge of each other and to communicate between them, in which case you will obviously need to keep references to the controllers.
So the answer to your question is probably just "it depends what you need". If you don't need a reference to the controller, there is no need to keep one. Indeed, in the standard use of FXML in JavaFX, the controller class is simply specified in the view (the FXML); the FXMLLoader instantiates the controller from that information and wires the view and controller together as needed. You often never even have a reference to the controller instance in your code at all. Though, as seen in this popular JavaFX question you can certainly get one if and when you need. In a completely "pure" classical MVC, all state change is made through the model, and the views observe it, so you would never need access to a controller. Fowler points out some nice examples where this doesn't work as cleanly as it sounds: firstly that some state, and associated logic, is really part of the view and has no place in the model, and secondly that the registration/notification mechanisms can make it very hard to debug your application.
You will need for a controller instance be created for you when a key is pressed on the GUI. So you will need it to be a Listener which listens to key presses.
Once you have a GUI listener registered, its the framework's responsibility to instantiate that controller and pass the view to that controller.
(So, you never need the handle to a controller - its handle is always with the framework.)
Next, when you are in the controller with the view, you determine which model to create or fetch based on the values in the view...
This is how all MVC's work...
I am attempting to develop a "Person database" Java Swing application, using MVC design paradigm with Observer/Observable. Here is a simplified abstract of M/V/Cs I am using:
App
AppModel
(Empty right now, possibly i'll store certain static application info such as version number here)
AppView
(Creates a JFrame and a few other Swing components)
AppController
(Instantiates AppModel, AppView and also a PersonController and a PersonListController)
Person
PersonModel
(Stores info for 1 person)
PersonView
(Displays a number of form fields inside a JPanel (i.e Name, Age, Phone number). Observes PersonModel.)
PersonController
(Instantiates PersonView. Observes PersonView. Instantiates PersonModel. Updates PersonModel.)
PersonList
PersonListModel
(Stores a list of Persons)
PersonListView
(Displays a list of persons with appropriate Add / Delete buttons. Observes PersonList.)
PersonListController
(Instantiates PersonListView. Observes PersonListView. Instantiates PersonListModel. Updates PersonListModel)
Also, a 'bootstrap', where the app starts. It creates a new AppController.
In the real application, there will be more (and different) Model/View/Controller objects but I want to keep this example simple.
I dont understand how I can go about 'merging' these seperate views into one UI while maintaining a good seperation of concerns.
Take for example the PersonListView. IMHO it doesn't need to care about the AppView (with the JFrame etc). PersonListView just needs to look at its own model and update itself accordingly. However, I cannot enforce that because the PersonListView's own Swing components need to be added to the Swing components of another view, the AppView.
So at the moment the AppController is instantiating its own View, plus indirectly a PersonView and PersonListView (via instantiation of their controllers). AppController then grabs the 'main' Jpanel for each view, grabs the 'parent' Swing components they should be added to on the AppView, and adds them.
This just doesnt seem the right way to do it to me. Im pulling Swing-related members from their hiding places and messing with them around inside a controller. In fact instantiating the model and view within the controller seems bad too, but I cant figure out a better way.
I've seen enough 'simple MVC' tutorials recently that I'm dreaming of the bloody things - but not one tutorial seems to go into the relationships of multiple models, views, controllers, especially where it concerns Swing. Maybe I am wrong and the App should have just one view? Maybe I need a 'Relationship' class that sort of takes every single Model/View/Controller and instantiates stuff appropriately?
Any advice would be most appreciated as Im completely at a loss!
This is where a strict MVC paradigm falls down (in Swing anyway, and it may explains why Swing is written the way it is).
Swing combines the view and control elements together, leaving the model separate. That means, you are free to add a view to any other view and the control follows (the model remains dynamic).
I have a developer who insists on using the strict approach to MVC and they still can't tell me the order of precedence. ie should the control know about the view or should the view know about the control - which one plugins into the other. Personally, I'm to lazy and simply follow the Swing implementation.
To my mind, if you want to follow a strict MVC, I'd basically allow for a public method in your controller that allows access to the overall view (say a JPanel with all the components on it that makes up the view for example).
Think about the JComboBox or JSpinner for example. They both have a number of components that make up the view (editors, buttons, etc), but you have single access point, the component itself...
Your next problem is going to be how to combine various views into a single over all view.
Personally, I would create a group controller of some kind that allowed you to supply the various, known, controllers together (setPersonList for example), as the "master" controller is going to need to know about these other controllers any way, as it needs to know how to layout them out.
IMHO
This is a follow up question to The MVC pattern and SWING. I am trying to implement the MVC pattern in an existing piece of code. The existing code creates a JFrame which acts as both the view and the controller. The JFrame has a table, and the table's model is an adapter to a custom data model. Whenever the user performs an action, the model would be updated by doing something like the following:
CustomDataTableModel cdtm = (CustomDataTableModel) DataTable.getModel();
CustomDataModel cdm = cdtm.getModel();
cdm.delete(1);
I've tried to visualise how it currently works, but I've also visualised how I imagine the relationships with the future controller and model should be.
Now, my question is simply whether I can continue using the model as it is now? Could I implement the following and still "adhere" to the MVC pattern?
The user selects an element in the table, and clicks on a delete button.
The view delegates the action to the controller.
The controller access the table through an accessor on the view, and performs the update.
The model, when it is updated, notifies the JTable that it has been changed.
If any other components in the view displays data from the table, then this could be solved by registering listeners on the JTable's table model.
Update 1
I've been thinking about the existing code in light of the MVC pattern, and I've redrawn the relationships a little. The point is that the controller is the behaviour of the view, thus the controller updates the model when users do stuff, and the view listens for changes in the model. However, nothing in the MVC pattern stops the view from listening to the model through a tablemodel - right?
Now, the user clicks the add button. The view notifies the controller that the add button has been clicked, and the controller takes care of creating a new item by invoking some method on the model. The view is registered as a listener on the model (through a table model) and updates its view. The controller may also be a listener on the model in case it needs to take care of disabling or locking fields. Have I not achieved what the MVC is all about; separation of concerns? As far as I can see, I've even introduced the adapter pattern to decouple the view even more from the model? It is late and I am tired, so that might be why it makes sense :-)
In the general sense, I would advise you the following:
take a look at JGoodies Binding,
it is not MVC but uses the
"PresentationModel" pattern
which is, in my opinion, better
adapted to a whole application than
MVC (which I find suitable for
individual widgets only). This should
solve your problem between your
Domanin Model and the TableModel
if your application has only tables,
then GlazedLists also makes a
lot of sense: it will also isolate
your Domain Model from your
TableModel (but it doesn't enforce
any global pattern, MVC or PM)
Regarding the current design you show, I would rather suggest that the View asks the Controller for an Action that the View will assign to the Delete button. Then the Controller can act on the Domain Model.
That gets messy and confusing fast, alas, and the code base is already confusing due to lack of separation.
I suggest instead migrating distinct components to a clean, simple MVC design. Such a component (which is currently a view, controller, and model all mixed up together) would then be separated in a clean fashion, however you will then have the difficulty of how to handle the controller and model?
As a temporary workaround, you'll be forced to designate the owner view as the controller, so the owner arguably has more responsibility. I think that this is a suitable workaround, because you will eventually separate more and more components into an MVC design, and the views that are also controllers will eventually become refactored as well.
In other words:
For a large application, identify a small component. (The low-hanging fruit).
Identify what code effectively controls that component. This is probably another 'view' class in this case.
Separate the component identified in step one into a clean design.
Explicitly configure the owner (view) identified in step to as the controller for the newly refactored component.
Repeat until there is clean separation between ALL views and controllers.
Be careful to ensure that the application is still working at the end of every 'step 4' above, otherwise, you'll find yourself in a mess that just gets longer and longer to fix. (Even if the end result is nice and clean, you may have missed your deadline).
Keep in mind that it may be difficult to extract the 'model' from the code at first - the controllers and views will be easiest to separate, but eventually, the models will become easier to separate as well. Whenever you manage to extract a model, write unit tests that test that model in isolation.
The presence of a well written suite of unit tests will help ensure that the application continues to have well-defined separation of concerns. (If concerns are not separated, then it becomes very hard to unit test), so the unit testing approach serves as a motivator.
I hope that makes sense.
i've started on some basic java coding with gwt, and im getting a bit concerned about the heft of my main class.
For instance - how does one compartmentalize the keyhandlers, since they trigger a number of changes to the UI, how could i move this into a separate .class file and still be able to access all the various widgets in the main class, without having to pass everything to the handler (ie. all the widgets i manipulate after the click event).
i've googled but didnt come across any particularly good examples - know of any readily legible code-bases i could read to see how it should be done? (gwt's own tuts are pretty basic, and just kitchen-sink every thing into a single file)
thanks!
I hate to say something so unimaginative, but MVC works--it's not the ultimate, but it can start getting you organized.
EDIT: While searching on a semi-related topic, I came across this which has similar ideas to mine but goes into more detail.
What that means in terms of GWT is that you should think of just laying out your GUI components in one class, put all your event handling in a second and put your object model objects separate from the other two.
One way to accomplish this is to make most or all the controls on your GUI public members. This sounds kind of lame, but their usage is encapsulated inside the controller so it's not like you have uncontrollable access--in fact your access is clearer/better defined than if all your members were private but your view code was combined with the controller.
Specific tricks:
Have listeners be their own class. You can often reuse them-- in other words, avoid anonymous inner classes. I sometimes create a listener class and instantiate a new instance for each button/control that needs to have a similar effect when pressed. If I need it to act slightly differently for a given button, I'll pass something into the constructor of the "special" handlers so that they know to act a little differently. You can also create different handler sub-classes if necessary--I'm just saying don't forget that event handlers are classes, you can use inheritance and everything if need be.
One Very Old GUI Trick I learned a long time ago, try not to have various mini-handlers modifying the GUI in different ways, instead have all the "active" buttons and controls set a state within your GUI and then call a single method that applies that state to ALL the controls on your GUI. When you get beyond a trivial GUI this can be a life-saver. If I'm not being clear, leave a comment and I'll leave an example for you.
Property sheets:
There is a special case for GUIs--the property sheet style GUI. I've done a LOT of these and they are irritating as HELL. They tend to have dozens or hundreds of controls on them, each GUI control tends to be tied to a specific field in your model and there are just hundreds of lines of copy and paste boilerplate code connecting them, each group copied and pasted with a few items changed--at minimum it's like 3 lines of code per control (Create control, copy value in and copy value out).
I always write these with a "Smart" controller--one that can intelligently bind the control to some data without any unique code. This can get tricky and if this is your problem let me know in the comments and I can give you some general advice as to some tricks you might try. I've gone from a minimal reflective solution to a full-on XML based solution. Were I to do it again, I might consider annotation-based.
Example of MVC:
Note, this is just an example, there are a MILLION ways to do MVC.
In your MAIN:
Instantiate MyView
Instantiate MyModel
Instantiate MyController(myView, myModel)
myView.setVisible(true)
in MyView
probably extends Frame
Most components are public final (public final Button b=new Button())
If public members make you nervous, use getters--same EXACT effect as public final members with a little extra syntax.
Remember that you can set final members in your constructor.
May have general methods such as reset(), but MyController may be a better place for this.
in MyController
saves references to myView and myModel
adds listeners to myView where necessary (see advice on listeners above)
configures myView based on state of myModel
when "done" button pressed, copies state from myView to myModel
notifies myModel that it's data has been updated and destroys itself.
in MyModel:
This would be a typical model class, it would contain your business logic (mostly not used as part of the GUI, that's more like GUI logic in MyController. The controller would tend to set values in your business logic then call some method like updated() to cause some business logic to take control. It should know nothing of a GUI--this is your "pure" business class.
Sometimes the GUI might call an update() or some other method to trigger some data change and then reload the GUI controls from the Model--this is a fairly good way to integrate your business logic with your GUI without your model knowing about the GUI...
Also, as I said above, I would put more work into MyController if I was working with property sheets just due to the sheer number of lines of boilerplate that you end up with if you aren't smart about it.
Note that View and Controller are nearly always paired. You can't just replace a Swing view with a web view and expect the controller to remain unmolested--but the model should not ever change for the view or controller.
You should take a look at the best practices for GWT applications first:
http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
One of the concepts they talk about is that of MVP (not MVC) to structure your application. There's a sample project on Google Code that you can look at to understand how to structure a GWT application in this way:
http://code.google.com/p/gwt-mvp/