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.
Related
I am currently trying to implement my first MVC pet-project. I understand the theory of Model View Controller pattern but when it comes to implementing a real application I am facing several logic issues.
My program is a basic Payment service system (i.e. PayPal).
Here is a typical flow of the program which demonstrates an issue:
Client clicks sign in button in View
A sign in method of Controller is called
This method returns an instance of a current signed in client BACK TO VIEW! (It constructs a client window passing current client as a constructor parameter)
Now when View needs to display some data of that client in client form it just uses that member instance directly.
It seems wrong to me, I think the solution here may be keeping an instance of current logged in user an exclusive private property of controller. But then it may be difficult to display all the data related to that user in View. I think I'll have to crete many 'getter' methods in controller which are going to return strings/strings arrays to populate the UI. It also sounds wrong to me cause I think it's still best to populate the UI with the model data, not some strings received from some controller functions.
What may be the best solution here?
Also, you might be interested in how I implemented MVC pattern in my program in detail.
The model includes Client and Staff entities which inherit the base properties from their superclass BaseUser and the two possible accounts: DebitAccount and CreditAccount which are subclasses of BaseAccount. Then I have a singleton PaymentService which stores all the instances of actors and accounts.
Here is a UML of my model
Then I have a view which is represented by:
EntryForm class — You can register a new client; log in a client or a staff member.
ClientForm
StaffForm — Admin panel
I have sketched/commented what looks like severe design fuckups to me(Sorry for the handwritting).
Here is a UML of my view
And controller
Your help and guidance will be much appreciated!
In a "classical" web MVC - please correct me if I'm wrong:
the controller passes the request data received from the "user" (be it browser, console, etc) to the model layer (consisting of domain objects, mappers, repositories, services, etc),
the model layer processes it and returns some result data,
the view - as specialized class(es) - processes the result data and sends/displays it to the "user".
I would like to ask:
Does the controller create the view?
Or does the controller receive the view as a dependency?
Or are the controller and the view created completely separately, on the front controller level (let's say in index.php)?
Thank you.
Your definitions of MVC in generally is right, here is answer for your ask:
Controllers are not responsible for rendering the interface, nor for
presentation logic. Controllers do not display anything. Instead, each
controller's method deals with different user's request. It extracts
the data from said request and passes it to model layer and the
associated view.
Decisions about what and how to display are in purview of views. Views
contain the presentation logic in MVC pattern. In the context of web
applications, views create the response. They can compose a from from
multiple templates or just send a single HTTP header.
Controllers can signal the associated view by passing some specific
values of the request to that view, but most of the decisions in the
view are based on information that the view requested from different
services in the model layer.
A Controller's methods are based on what type of requests a user can
send. For example in a authentication form it might be: GET /login
and/or POST /login.
Source: Controllers, tereško
Classic correct MVC class structure:
Easy definition:
Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
View. The view manages the display of information.
Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.
Source: Microsoft Docs
Additional resourses: (only useful ones)
External
MVC Explanatory [computer science design patterns]
Creating a Custom Controller and View in CodeIgniter [a visual example]
Codeproject's definitions MVC: easy | extended
Internal
The relationship between Model, View and Controller
MVS in a conversation form
The controllers are entry point of MVC, controllers call to model , and model check wich view display , example, magento (mvc)
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
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.
In MVC, where is the correct place to put authorization code?
The controller?
The Model?
In the view?
All over the place?
I vote for putting it where it makes sense. Most of my authorization stuff is handled via decorating controller actions (or even some controllers) with the AuthorizeAttribute -- or an attribute derived from it. In a few cases -- like my menus -- I've resorted to putting the authorization check in the view code itself, rather than calculating it in each controller and passing flags down in ViewData. There are a few instances where certain aspects of the model are only available to particular roles and in those cases I've resorted to extending the model with methods that can take the current user and roles and do the check there.
I think authorization is a cross-cutting concern. Should be in one place - an aspect that can be declaratively applied where it's needed.
The Controller!
Your View should only handle user interface and display
Your Model should represent the data in your system.
Your Controller should handle the logic of how the system works.
Authorising a user involves taking the credentials provided from the View, checking them against some sort of authorisation list in the model and then performing a check.
This is done in the controller:
Get user credentials from View
if(compare with user list in model returns match)
authorise users
else
refuse access
If you have to choose between M, V or c, the C is the correct place. But, I recommend an architecture where your app is all contained in libraries and the UI is just a thin veneer. You end up calling down the stack from the Controller, but the code is not in the controller.
In MVC, the Model is just a model, or a "dumb data object", if you will. It is designed to hold state, and should not dictate behavior. The View is for the user to interact with and is also "dumb"; the view handles UI. The controller is where behavior sits, or is the entry point into behavior in the case where the app logic is in libraries. Make sense?
Model.
Controller is just for switching through different ways. View is just for... viewing.
So you should make all authorization codes in the Model layer. Ideally, everything will work just fine. If not, then the controller will take the user to the proper login box.