Lets's say I have a backend web API. It takes in a web request and returns some json. Other services then consume that json and do what they will with it.
My question is twofold:
1) Does this backend web API technically have a view (v in MVC)? My thinking is no, since it doesn't actually display any frontend to the user.
2) Does the JSON object returned represent a model (m in MVC)?
Thanks!
1) Does this backend web API technically have a view (v in MVC)? My
thinking is no, since it doesn't actually display any frontend to the
user.
You are correct, it doesn't really have a View.
The Web API itself is simply going to return some data that was requested or something to indicate to the user that a request was performed properly (e.g. a JSON-formatted object indicating that a user was created, a collection of user objects, etc.)
Although a front-end could call the API and then use that information to render something, the Web API on it's own isn't going to do anything like that.
2) Does the JSON object returned represent a model (m in MVC)?
It can.
Each component of the MVC pattern plays an important role :
Controller - Responsible for things like data access and possibly populating a model.
Model - Responsible for representing the data that was accessed or for some type of operation.
View - Responsible for taking the model that was passed along from the controller and serving it to the user.
In this case, when you hit your Controller, you will likely be accessing some type of data and building a model. This model might use some business logic that you have designed yourself, or it might simply be content that was returned from your data layer, either way, the model, regardless of how it was created merely represents some type of data.
The "Model" is this case can be any type of data that you might decide to pass along to a View. Regardless of how it is serialized, if it is consumable either by a View or some other mechanism, you can think of it as a model.
Related
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)
Here's an example structure of the DB I have:
In the Student view form, I've added the form to add a file.
In the Student Controller, when I create or update an entry, I manage the file upload and the creation of the File database entry.
What I want to know is, in the MVC design pattern, what is the right way to do this ? Is it that my Student controller must be aware of the way my File model is done and must know how to add a file?
Or the best way to do this would be that in my Student controller, I call the add or update action of the File controller? But in that way, am I breaking the MVC ?
Thanks!
Ways you are breaking the MVC:
controller being responsible application logic and maybe even persistence (it should only be changing the sate of model layer and view)
model is not any single class, it is a layer made up from different classes with different responsibilities (there is no "file model" or ""student model")
In best case scenario, the controller would have no feedback from data, that it passed on to model layer (preferably through some service, that would be dealing with application logic withing domain model layer).
Instead the view instance, when it starts to assemble the response for the user would check up on model's state (through services again), to see if there has something changed. In case of an upload, this would be the point where view discovers the result of your upload and, based on data, decides how to respond. Usually in case of file upload the response will contain only a HTTP location header.
I am assuming that you are talking about MVC in context of web, based on your profile history. In classical MVC the view would have know about changes in model layer without explicitly checking it, because of the observer pattern which is used there.
While you most likely will have some "upload controller", it should not directly interact with domain objects or storage abstractions. Instead it just takes a user's request, extract data from it and passes it where it needs to go.
Keep in mind, that in web applications the "user" is a web browser, not the person that works with it.
I've learned that you should set up the controller-class in a MVC-OOD as a use case, from top to bottom in only one method that run the MVC-classes.
Is it OK to use different methods in one controller to get more control and better overview?
Let's say you wanna run a controller that will display a login form (getting the html etc from the View). And the same controller will also display a log-out button IF the user is NOT logged in.
This could be done with a single method in the controller, but using two methods seems better. One method to call if you want the login form, and one to call if you want to log-out button.
(just an example)
So, what does the pros say. Should each controller contain one "use case" method only, or could it be several?
TL;DR -- you have misunderstood the MVC design pattern and are doing it wrong.
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.
Its important to remember two things with MVC, firstly, its an Object-Oriented Architecture, and secondly, It should be used for separating concerns.
Separation of Concerns is related to Abstraction, It is to aid us in understanding the section of code at hand. The Model and View are both collections/domains of related objects. Each object is fully complete and relevant to its domain.
You will find objects with types such as Buttons, Images, Text Inputs etc inside your View, and you will find business related objects (User, Account, Profile etc) within your Model.
The collection of objects inside your Model don't tend to do much, They require logic to wire the objects together. (Or simply delegate simple single object requests to the correct object)
The Controller provides the interface into your Model, and contains the business logic related to the Model and the interactions between the Model objects. You will have a single Controller for your Model, and the Controller will have multiple methods which will align with your use-cases.
can any one tell me the difference between request.setAttribute and model.addAttribute in spring web app?
The difference is, that Model is an abstraction. You could use Spring with servlets, portlets or other frontend technologies and Model attributes will always be available in your respective views.
HttpServletRequest on the other hand is an object specific for Servlets. Spring will also make request attributes available in your views, just like model attributes, so from a user perspective there is not much difference.
Another aspect is that models are more lightweight and more convenient to work with (e.g iterating over all attributes in a model map is easier than in a request).
Request V/s Model
where request could get attributes through getAttribute("") method. normally it is used for getting information from defined attributes and used inside the method for performing the different operations. So Basically Request used for input.
Just like Request, the model provides addAttribute("","") method, Through this model, we could make the object and storing data inside model object and deploying it on result Server Page.Basically it used in storing input data which is provide by us and storing for some time.
So I did some Google searching on the MVC pattern and I'm still not exactly sure what the "Model" part is. What exactly does it deal with? I'm rather new to programming so all the explanations I can find go right over my head. I'd really appreciate it if you could give me an explanation in simple terms.
Thanks
The simplest way I can describe it is to call it the "Data" part. If it has to deal with getting or saving data, it's in the model. If you have a web application, the model is usually where you interact with a database or a filesystem.
Model in MVC is a place where data presented by the UI is located. Therefore, it shouldn't be confused with Domain Model which serves as a skeleton that holds the business logic.
Certainly, for a small application that serves as a service for CRUD operations backed by a database these two models can be the same. In a real world application they should be cleanly separated.
Controller is the one who talks to the application services and the Domain Model. It receives updates back from application services updating the Model which is then rendered by the View.
View renders the state hold by the Model, interprets User's input and it redirects it to the Controller. Controller then decides if the Model is going to be updated immediately or first the information is forwarded to application services.
The Model can represent your "Domain Model" in smaller projects. The Domain Model consists of classes which represent the real-world entities of the problem you're dealing with.
In larger projects, the Domain Model should be separated out of the actual MVC application, and given it's own project/assembly. In these larger projects, reserve the "Model" (i.e. the "Models folder in the MVC project") for UI presentation objects (DTOs - Data Transfer Objects)
The model is respomnsible for managing the data in the application. This might include stuff like database queries and file IO.
the view is obviously the template, with controller being the business logic.
The model is used to represent the data you are working with. The controller controls the data flow and actions that can be taken with the data. The view(s) visualize the data and the actions that can be requested of the controller.
Simple example:
A car is a model, it has properties that represent a car (wheels, engine, etc).
The controller defines the actions that can be taken on the car: view, edit, create, or even actions like buy and sell.
The controller passes the data to a view which both displays the data and sometimes lets the user take action on that data. However, the requested action is actually handled by the controller.