I have a question about model view controller design pattern.
I am going to explain my thoughts about my question.
if in my model I have an interface called iModel. I have two classes which implements iModel. First class is called Game1 and second class called Game2
In my view package, I have a Gui class which takes in an iModel instance and makes a game using iModel instance. e.g GUI(iModel m)
Since I pass in iModel, I can pass in two different games but one at a time.
One game
iModel m = new Game1();
In view, Gui(m) will create Game1
Other game
iModel m2 = new Game2();
In view, Gui(m2) will create Game2
Now this concept is basically I am passing in multiple models(only one at a time) into the view. The view is just going to be the same but with different data depending on the game(model) chosen.
Now my question is, is that MVC? I read some stuff about MVC is about sending in a model to create all different types of view for that model, but my thoughts are,if passing in different models into the view with the view just the same. Does that count as MVC?
Thanks
Now my question is, is that MVC?
From a purely technical stand point, no, because you don't actually have a separate controller, but it is a step in the right direction ;)
I read some stuff about MVC is about sending in a model to create all different types of view for that model, but my thoughts are,if passing in different models into the view with the view just the same. Does that count as MVC?
That's correct, but I think you might misunderstand what it's saying. The model doesn't care about the view, it doesn't care how the data is represented, it only cares about up-holding the contract (specified by the interface) that the views expect.
Equally, the views don't care about how the models are implemented, only that the models up-hold the contract of the interface.
This means that a model might be used by multiple different views that represent the data differently. Equally, it might be visualised by only one. The point is, the model shouldn't care.
So I would say your point of view is okay. A view can represent multiple models over it's life time
Remember, the point of something like the MVC paradigm is to clearly separate and define responsibility between the layers and to decouple the relationships between the layers.
Food for thought...
In iOS development, there is a clear separation of the model and view, to the point that neither should interact with each other, in fact, all the communication between them is handled by the controller. This can sometimes seem at odds, as you want the model to tell the view to update something.
By allowing the controller in this case to act as a proxy or delegate between the model and the view, you actually further decouple the relationship, as you can slide in a new controller which might have it's own view and provide functionality to plugin in view, the point is, you just shouldn't care.
Just so you are completely confused now ;)
Related
The MVC pattern component interactions are described this way on Wikipedia:
The model is responsible for managing the data of the application. It
receives user input from the controller. The view means presentation
of the model in a particular format. The controller responds to the
user input and performs interactions on the data model objects. The
controller receives the input, optionally validates it and then passes
the input to the model.
I understand that the View should not be able to interact with the Model. But in most of the diagrams I find on the net, MVC is represented like this:
We can see that Model does interact with the View and is able to modify it, and it doesn't make sense.
Doesn't the Model update the Controller, that updates the View?
What am I missing?
The MVC architecture was created in the 1970s. Obviously there was no Internet at that time. In the original version, the Model directly updates the View through data binding, also known as publish/subscribe, also known as the Observer Pattern.
The Gang of Four Design Patterns book describes this MVC architecture in detail. A couple of quotes from that book are in another answer here.
The MVC architecture was very popular, and when the Internet came along, developers wanted to continue using it; but it didn't fit nicely into client/server applications. Thus was born "WebMVC", the version you most commonly see today. WebMVC is typically implemented as a layered architecture, which the original was not.
Confusion ensues when the two architectures are conflated. Often both are referred to simply as MVC. Even worse, related architectures such as MVP and MVVM can be called MVC.
Personally, I find the relationship between desktop MVC and web MVC somewhat like the relationship between Java and JavaScript. The latter piggybacked on the famous name of the former, to implement something significantly different.
related: Is it MVC when the view doesn't interact with the model?
No you can't access view with model directly, you must access controller first
as its MVC Pattern
Diagrams - worth a thousand words! The precise words and context used in the diagram maybe doesn't tell a story of implementation, say in Microsoft MVC 5/6.
A user's interaction is with the controller. Not the view and not the model. Calling an action on a controller will return something (a view, a file, a redirect, etc.).
In the case of returning a view of information, the controller, having worked out what data the user is requesting can retrieve a model that fits the request, pass this into a view, and return the view result of this model.
In the diagram above it isn't clear that the controller is acting as the agent in moving the model into the view. the model does not decide on the view. Why? Depending on what is in the model returned the controller, a different view might be returned. That is why the controller is aptly named. It sits at the centre of affairs making decisions and moving objects around.
So what you are missing is some context about how the process of MVC occurs when implemented
I'm still trying to understand what is the correct way of implementing MVC. This example #oracle says that view has access to the controller. And another tutorial #leepoint is indicating that the view has access to model. Are these different variations of the the MVC? In my case I was following the tutorial at Oracle site with some modifications(I have added a function in AbstractController getModelProperty, which will allow me to retrieve the value of the fields of the current registered models, but it also could me sense to pass the model as parameter(like indicated at leepoint tutorial) to simplify and probably optimise the data access for the view.
Thanks in advance.
Views are bound to models. Since views render models, they have to have intimate knowledge of the model, there's simply no way around it. Some views are generic, and these have "generic" models. Here, you may try and conform your actual model to the generic one so that the "generic" view can use your data. But even with these generic models, the views are still tightly bound to them.
Models manage data, the state. While a view has intimate knowledge of the model, the model is view agnostic. It simply doesn't care. This way you can have several views for the same model.
However, a model must inform others of changes to the model. Typically in java you use PropertyChangeListener's. This mechanism lets the model just shout out changes wholesale, and anyone interested can listen for these changes and act on them, for example your view.
A simple example is that you game object can take damage from a bullet, and it's reduced to below 50% health. The view can see that health has been reduced and change the image of the model (say adding smoke, or whatever).
The Controller typically is bound tightly to the view and the model. It knows the capabilities of the view (like it's size, and other areas of interest), and it knows how to change the model. Such as when mouse is clicked, the controller converts the mouse point in to a coordinate relative to the view, and from that determines what object was clicked. Once it determines the object that was clicked, it can set the model for the object to, say, "selected".
The model then broadcasts out that it's "selected" property has changed. The view sees this, finds the bounding rect for the model that changed, and invalidates that rectangle on its display.
Finally, Java comes around and tells the view "Hey, Rect 10,10,100,100 needs to be painted". And the view find the models in that rect, paints the new view of the object with a "selected" border, or whatever.
Thats how the whole cycle works.
It's both. MVC has a triangular relationship with each other, with the Controller on the top. The newer way to go is using MVP, where the Presenter sits between the model and the view.
It's better if you can keep as much of the model knowledge out of the view and only feed it information specific to it's viewing task. It does make your life easier in the long run.
... says that view has access to the controller.
yes, the view holds a reference to the controller for user gestures. (in a gui, the view and controller sometimes end up lumped together).
... that the view has access to model.
yes, the view usually holds a reference to the model(s) (it might have more than one).
... Are these different variations of the the MVC?
there are a bunch of variations.
... but it also could me sense to pass the model as parameter(like indicated at leepoint tutorial) ...
usually the model has views that are observers and the view updates itself when it receives an update message as opposed to being called directly by the controller. the former decouples the view more from the controller.
The Swing libraries are a very good implementation of the MVC pattern. Just study the API for a bit and it will all fall into place for you.
The Wikipedia Article on MVC nails the relationships pretty well: View has the Model, Controller has both the View and the Model, Model knows nothing about both View and Controller.
In some cases it may be advantageous to simplify the pattern by combining View and Controller.
I have a model with a reference to the view, a controller with references to the model and view, and a decoupled view, with no references to the above.
The controller has all the listeners of the view, and takes care of events by calling methods on the model and view. The model calls methods on the view in some of it's methods.
Is this bad for maintenance and reuse and should all view methods be called only in the controller? Also, i haven't set up the model as the observable and the controller and view(s) as observators, as seen in some examples. Is this common practice to do so?
I would avoid coupling directly from the model to the view, or at least only as very special circumstances (and even then, this might hint that the state being manipulated is not true model state, but presentation state.)
In general, the model uses listeners to notify of changes rather than a direct coupling to the view. The view can have a direct reference to the model, so that it can get the data to display. Although this may not be strictly necessary - all changes can be propagated from the model to the view as listener notifications, at the time the view needs it, but this is usually a bad idea, since it couples the rendering of the view with notifications from the model.
To sum up, the controller makes changes to the model, which notifies interested parties (including the view). The view has a reference to the model to retrieve data.
Following the classic MVC pattern, a model would not have direct access to a view. However, indirect access - such as via an observer - would be helpful to alert the view to changes in the underlying data.
The model should not know anything about the view.
The view should know how to populate itself given a model.
If you model is going to change it might want to make the view know of any changes so the display can change.
There are so many flavors of MVC, that i will decline to call any as "wrong".
See http://martinfowler.com/eaaDev/uiArchs.html
Look for one fitting flavor and go with it.
On the desktop Swing is a good GUI library. Check out this article to see how it relates to MVC. For the enterprise, take a look at Martin Fowler's Model View Controller pattern (330) for web-based applications. If you don't have his book (Patterns of Enterprise Application Architecture), I highly recommend getting hold of a copy.
There's a nice blog article at Sun.com: Java SE Application Design With MVC. It starts with explaining the "classic" MVC pattern where the view and model interacts directly with each other and then goes on with the newer "centralized controller" MVC pattern where the view and model can only communicate with each other through the controller (model is decoupled from view). It contains a Swing targeted example as well.
I have a bunch of model objects.
These objects end up being rendered as views (say forms) in a rich client app.
I started to annotate the fields in the model objects (Java annotations) with things that let me render them as forms on the fly (e.g displayname, group, page, validvalues).
I now realise that the view has crept into the model.
How should I seperate the view logic out of the model objects?
TECH: Java, Java Annotations, Eclipse RCP
EDIT:My question is theoretic, but I would also like some concrete (implementation) advice.
At the risk of stating the obvious, what you need to do is store the display-related information somewhere else. Don't put the page in the model code - create an object for the interface, have it contain page objects, and make each page know what values it displays. This may require a certain amount of refactoring.
Having said that, not everything you mention is 'view'. Valid values for a field is part of the logic of the field; it should be considered part of the model, not the view. Likewise if 'group' is a logical grouping, rather than about placement in the interface, it might be considered part of the model.
You could replace the annotations:
#DisplayName("My Fancy Name")
#DisplayGroup("My Fancy Group")
public String myProperty;
by a separate descriptor class:
Descriptor desc = new Descriptor(MyClass.class, "myProperty");
desc.setDisplayName("My Fancy Name");
desc.setDisplayGroup("My Fancy Group");
You have clean separation of concerns, but you loose compile time safety (in Java, because Java does not have property references).
You could look at the MVC pattern and introduce a controller into the mix to provide the communication between the model and the view.
This prevents the view creeping into the model as the view never talks to the model it only talks to the controller which is responsible for all interaction between the model and the view
If I get you right - you use the model classes as a (static) model to create (part of) the view? Why not - in your case, the model classes (with annotations) are one model, the objects another one.
As long as the annotations just give hints (like #Textfield) I don't see a problem. If the model already contains references to view objects (like a reference to a Textfield), then there's need for refactoring. Easiest would be to move the model classes in a separate plugin and do not add any *.ui type and view plugins as dependencies. Then fix the errors ;)
... and have a look at jface databinding! Very useful in a MVC/MVP architecture!
The view should have a reference to the model, but the model should not have a reference to the view.
The view can write to the model.
The view listens for events on the model, such as a property change, or collection change.
The view then updates itself when the model changes.
You should definitely not have methods on a model that render the model as a view.
I am developing an application in Java, in my GUI I have several JPanels with a lot of settings on them, this would be the View. There is only one Model in the background of these several JPanels. Normally, I would Observe the Model from the JPanels.
I was just wondering, is it good practice to Observe View from the Model? Because, the user changes the View, and this change must effect my Model. Or am I missing some important principle here? Thank you for your help..
I think its great you are questioning this.
What part you are missing that could help is a Controller.
Check out http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller for an example.
Basically a controller is the mediator between a model and a view. It "Controls" the application. The only thing that your view should know about is the data that is being passed to it and how to display it. The only thing your Model should know about is data. The Controller ties these two together and contains the business logic that acts on the data and prepares it to pass to the view.
What you get from using this design is a loosley coupled and easy to test application. It really is elegant IMHO.
Cheers,
Mike
That would create unnecessary binding between the model and the view. But also think about an infinite cycle that you could get into.
What if the model was also updated by something other than a view, perhaps a web service? Then a change in the model through the web service will result a change in the view as the view would be observing the model. And also a change in the view will trigger a change in the model as the model is observing the view too. See the recursion here? It's not too difficult to bypass it, but will result in a really bad and unmaintainable design.
To tie your model and view together, one solution as has already been proposed is to add a Controller so that you have the full set of Model-View-Controller components implemented. This introduces a very tight coupling between all three components, which from a unit-test perspective is not really desirable.
An alternative would be to consider the Model-View-Presenter pattern. The Presenter would be the intermediary between the Model and the View, and would update the Model based on any input from the View, and would also be responsible for updating the view based on any changes in the Model. For your unit-tests, you would then be able to substitute a mock-View to test the Model, or a mock-Model to test the view (or mock both to test only the Presenter).