can anybody tell me, why communicates the model direct with the view in the MVC pattern, and why not just throught the controller?
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Sometimes it is too costly to use Controller for simple View/Model communication.
If your view just shows raw data without any operation (filtration, visualization, modification ...) it is easy to forget about Controller.
But this behavior is so abuse-able sometimes it kills all of the advantages of MVC.
And this where MVP comes in:
MVP (Model-View-Presenter) cuts the connection between model and view and every thing pass through man-in-the-middle (Presenter).
The views know of the model and will interact with the model.
If a button is clicked an action message might be sent to a model object in order to get
something done.
If a new value is typed into an entry field an update message might be sent to a model
object in order to give it its new value.
If a value is needed for a display an enquiry message might be sent to a model object in
order to get a value.
Related
If i use the MVC pattern to create my Spring project, is it wrong to call the Controller from the View?
Is this schema right?:
View calls the Controller
Controller performs operations and put data result into the Model
View reads data from the Model
Edit:
In my index jsp there is a menu with several categories of articles. I want to pass the name of the category to the controller. The controller calls the method of a beans which executes a query and returns the list of articles presents into the database.The Controller puts this list into the model and the View read this list from the Model.
Thanks
What you say (in your comments) is not specially wrong, but it does not make sense.
Either the categories are known when you build the view, and then it is the controller role to collate all information and put it into the model before calling the view with the model.
Or the category is chosen through a user interaction. But at this moment, the JSP is over for a long time : the response has been committed and transmitted to the browser. The only possibility is to prepare a new request (with a form or with ajax), send this new request to the server, where it will be handled by a controller, which will collate data into a (new) model and pass it all to a view
Depends what you mean by calling. But yes, View doesn't know anything about the controllers. It sends HttpRequests, and than the mechanism doing what you describe kicks in. There's the famous schema from spring docs, basically your bullets described via diagram. The point with respect to your question is that the view doesn't call the controller rather sends the request
I think you will find your answers in article mentioned below :
http://docs.spring.io/spring-framework/docs/2.5.3/reference/mvc.html
I have the action contlrSaveText() in controller and the method modelSaveText() in model.
When the data comes from the website to the contlrSaveText(), I check whether the required information is received to save text, i.e. text name, text content etc. Then I call modelSaveText() to actually perform saving text. Do I need to validate data in this method as well or I can expect that controlled already did the job?
A model is only an abstract description, while a controller does the work.
Your model might have a controller on its own that take care of the data and updates the model. But that is technically a controller.
How he works with toward the outside, e.g. another controller that fills data in, is up to you how you define the interface. If your model uses relations or properties that require to be set up by the controller then you have to validate the data before inserting/accepting. But if not, then there is no point in validation and it can be skipped for performance reasons.
If you need to reject invalid data you have to think of a way how to tell the outside what whent wrong so it can respond to the error.
In your example I would go for validation, but that is just my opinion.
Suppose, as part of an iphone application, I need to show user a list of some of some objects.
The model
Represents actual objects to be shown
Brainless data, collection of getters and setters
The view
Displays the list, passes received actions to a controller
Presentation layer
The Controller
Interprets actions received from the view and takes actions on data
Sits between the view and data
In this picture, would be be controller's responsibility to persist model to disk, or, should it be a part of Model's logic? Request to do this will come from a controller, but, should the controller know how to save data to disk, or should data know how to save itself to disk?
This is wrong.
Model is responsible for all the business logic. Additionally model is not directly aware of database or any other data storage medium. When model is initialized it receives factory for creating DAOs or DataMappers which are the ones responsible for storing and retrieving the informations.
Controller interprets the received information from view , and changes the state of model and view.
View either receives information from a persistent model via observer pattern ( classical MVC ) or request data from models ( Model2 MVC ).
I can see this going both ways. I would think that this logic goes into the model this way the controller is a little cleaner. Also, if you're using this functionality across models and it's mostly consistent e.g $person->saveData(), $user->saveData() then you could possible extend the base model so it would be inherited by other models and save you from duplicate code.
If this logic is incorporated into the model it would probably be a good idea to make it flexible enough so that the controller can override the persisting of data. So maybe, pass an argument into the model function $person->save( false ) This false would prevent the model from persisting the data but on default would be true.
In my world, the model notifies only the controllers subscribed to the model's event. Then the controller tells the view what to do, for example adding a new row to a list.
The same with the view: the view notifies the controller subscribed to the view's event. Then the controller modifies the model as needed, for example setting the name of a person, and call the Save() method on the model.
Okay, I know I'm wrong, I don't think every article about MVC is wrong because I'm thinking in another way. The point in MVC is to seperate the UI from the data model. How does this come true when the view and the model reach each other? Why should they do so?
Thanks for Your answer!
Model-View-Controller is seen different ways by many people, but I like to think of it as a combination of several other patterns rather than as a single pattern. This may come originally from this note
The connection of the view to the model is an Observer Pattern, with the model notifying the view when it has changed. There's no need for the controller to be involved in this.
I completely agree with you on this one.
For every project i work on, i try to enforce this:
View --> Controller --> Model
So that every action or event in the view call a specific controller method. This controller method will do his job (validate, call other service, etc) then if persistence is needed, it will the call the associated ModelService to persist the data.
in my world, a view component should never call a ModelService without going thru a controller.
But that's just me ;-) (and almost 100% of the good architect and designers i worked with)
I like to think of the model as a transparent thing, adhering to some sort of scheme. Very easy to "read" by a view. I never make my views programmatic, in the sense that you can call all sorts of methods on it. Usually my view is HTML, my model has methods but is also capable of presenting itself as a plain data structure, and there is an intermediate: in the form of a template engine.
But, there are lots of variants for MVC. I don't think there are 2 developers who would exactly, exactly, agree on what MVC actually is. MVC is -in my view - a pattern to help you. It is not a law that is trying to hold your creativity back by exactly defining up to the last bit what you have to do.
I'd like to know where the controller gets the user input from (to feed the model with). Because input media is strongly related to the user shouldn't the view be aware of the concrete way to get the user's data? But how can I separate the controller from the view then? Is it possible to make both completely independent of each other as their purposes suggest?
Example:
When I have an application which uses the curses library for the view it implies that the it's only accessible through the terminal. Using curses methods to read user data in the controller would break encapsulation but calling methods on the view would have nothing to do with displaying the model.
IN MVC, the controller gets its user input from the View.
Consider having the View and Controller communicate through the Observer pattern. The Controller registers itself as an Observer with the View. When the user inputs data into the View and presses Enter, then the View interprets the data and notifies its observers that there is data available. The Controller can then get the data from the View through a public method.
I dont think that the view really has much to do with inputting data actually. I find MVC much easier to visualise if you see the user as communicating with the controller directly. A controller receives data from the user and sends views back. In many systems the view engine has some limited way of updating itself (ie text inputs display what is typed before it is sent to the controller). But for any MVC type architecture you can replace any view with any other view provided they are both capable of handling the same data.
For example. Entering a username can be done on any system that supports entering strings. The controller accepts a string, and so can be used in a web application, a terminal application, or a GUI application.
I think the view should have a callback on the controller to send over user input. In web architecture, the callback is provided through the ability to send the user input back to the server through http requests.
In your case, your ncurse front should probably have some kind of callback method to the controller component to send back user input.
Well,
I'll try to be more specific for you. Giving vague/abstract answers for ppl that you can see, doesn't master the subject, doesnt help.
MVC -> Model View Controler
There are many implementation of MVC, I don't know your case, but I'll give you one.
The most common MVC implementation acts like this..
view <-> Controler <-> Model
In a web scenario..
The view would be your HTML pages and data input would happen in a form.
<form action=/home/createuser method=post>
...code goes here...
</form>
Home would be your controller (a class named home), and createuser a method in home.
public class Home extends Controller {
public void createUser(Userform f){
...create user...
}
}
This form would submit data into the method as parameters. Createuser would them processed to talk to the model and later persist the data if thats the case.