Question 15578 in Laravel Question posted in
The official Laravel Documentation can be found here.

Who passes the response to the user in the MVC architecture? The controller or the view? – Laravel

I saw many resources online with different graphics about MVC architecture. Some of them show that the View component passes the presentation to the Controller and the Controller provides the user with the response; like this: first graph
see how the View fetches the presentation and the controller sends the response

The other ones show that the View component directly presents the results to the user without interacting with the controller; like this: second graph see here how the view sends the response directly to the user and the controller only interacts with the model and passes data to view

This confused me a lot, especially after seeing 2 articles on GFG, each one explaining MVC differently. So which one is correct? if the first case is correct, then who is responsible for the rendering?

PS: I am working on a laravel project and need to know this information.

Tags:

6

Answers


  1. 0

    Normally, it should be the controller, but simply think of of who and where the return statement is being called. and thats the one who passes the response back to the requester, but the actual response structure is handled by laravel router, its the one that constructs the actual response headers and body

    Here’s an example you can argue with your ideas and who passes the response

    // we could say response is process by closure/anonymous function
Route::get('/test-1', function () {
    return 'Response 1';
});

// we could say the response is process by response helper function
Route::get('/test-2', function () {
    return response(['test' => 1, 'test2' => 2 ] )
        ->header('header1', 'value 1')
        ->header('header2', 'value 2');
});

// we could say the response is process by response helper function but also calls the view method for the actual response body and status code
Route::get('/test-3', function () {
    return response()
        ->view('test', $something, 200)
        ->header('header-1', 'value1');
});

    But normally in Laravel, you should pass the route to a controller which process the data then make a return statement, which you could say the controller is the one who make the response and if you want to return an html body then you should call the view method to construct the html structure.

    i.e.

    Route::get('/test-4/{id}', [YourController::class, 'method1']);
Route::get('/test-5/{id}', [YourController::class, 'method2']);

    Then your controller

    class YourController extends Controller {


    // return with view
    public function method1($id) {

        $data = YourModel::find($id);

        return view('model-view', compact('data') );
    }

    // leave laravel router to transform your data into a json format when returning to the user
    public function method2($id) {

        $data = YourModel::find($id);

        return $data;
    }


    // format your own json as the response
    public function method3($id) {

        $data = YourModel::find($id);

        return response()->json(['data' => $data ], 200);
    }
}

    Take a loot at here

    Its safe to assume like this

    who passes the response back to the user? – Its always the router that handles eveything be it a string, json, html, files, exception etc. its the one that handles the response headers and body

    who made the response? – whoever has the return/render statement or whoever throws an error.

    does view passes the response directly back to the user? – always No, everything is pass back to the router which process the response. view is only a wrapper for dynamic html formatting. with the rise of front-end framework and even with laravel internal support for react and vue, view will never be use unless you use blade template

    Login or Signup to reply.
  2. 0

    Update

    In this article on the Model View Controller, it says in part:

    In addition to dividing the application into these components, the model–view–controller design defines the interactions between them.

    • The model is responsible for managing the data of the application. It receives user input from the controller.

    • The view renders 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.

    Nowhere is mentioned which type of object sends the presentation to the user

    In reality both diagrams are technically possible, but the second diagram, which unfortunately lacks adequate description, is potentially less misleading. Data, typically in the form of a model object, is sent by the Controller to the View (there is another possibility, which will be described) and then the View uses that data to create the presentation that will be sent to the user. The View then typically sends the data to the user but it can also return it back to the Controller who does the actual sending. Only in that sense is communication between the View and Controller bi-directional. But in the end it is the View that has the responsibility of creating the presentation.

    Let me elaborate:

    Controller

    1. Responds to events generated by an "actor." By actor I mean anything external to the application under discussion (e.g. a person, another application, etc.) that interacts with the application. So a typical example would be responding to events generated by a "user", such as mouse clicks, form submission, application to application requests. So a controller object clearly handles input.
    2. The controller uses the input event to implement a "use case", which represents a particular usage (scenario) of the application that achieves some tangible goal. As such it makes calls to potentially multiple model objects that may know nothing about one another and is therefore performing business logic "at a higher level."
    3. Finally a controller object in general produces some sort of result from calling model objects. Sometimes the controller then passes to a view that data and the view itself may send a presentation of that data to the user or return it to the controller for presenting to the user. It is also possible that one or more view objects have registered themselves as "observers" of changes to some model object. Then when the controller has modified the model, the views are notified and respond by asking the model for its data and then using that data to update its presentation without any involvement by the controller.

    Model

    A model object typically represents some entity in the problem domain, such as a customer, an account, etc. or a result generated from the execution of a use case. It performs the create, read, update and delete (CRUD) operations (data logic) on data that gets encapsulated as its state and exposes methods (business logic) that operate on its state.

    View

    I have already said much about the View in discussing the Controller, so please excuse any repetition here.

    A result obtained by the controller generally needs to be "viewed" by an actor. Sometimes the controller passes dats to the controller, quite often as a model object, and the view then presents it in some format to the "user" (actor). For example, in a web application a view object might transform the model object into HTML and then send the HTML to the actor’s browser or return the HTML back to the controller, which does the actual sending of the HTML to the browser. Or there could be multiple views on a single model object that are sent to the user, which occurs frequently in GUI-based application. In this case the view objects register themselves as "observers" of a model object and are notified whenever the model object has been updated. The view objects then retrieve the updated model data and use it to update the presentation with no interaction from the controller.

    Login or Signup to reply.
  3. 0

    Simply every interact with user is in controller.

    As you get request call a controller function.

    When you want to return a produced response either view or JSON or anything you do it in controller!

    So your answer is controller. And you see it in both diagrams.

    In first one controller gets view and sends.

    In the the second one controller sends view to user and user interacts.

    Login or Signup to reply.
  4. 0

    In the Model-View-Controller (MVC) architecture, it is the responsibility of the controller to receive user input and determine the appropriate response to send back to the user. The controller is responsible for processing and interpreting the input, making decisions based on the input and the application’s logic, and then updating the model accordingly.

    Once the model is updated, the controller then passes the updated data to the view, which is responsible for rendering the response to the user. The view receives data from the controller, formats it appropriately, and then presents it to the user in a way that is visually appealing and easy to understand.

    Therefore, while both the controller and the view play important roles in the MVC architecture, it is ultimately the controller that passes the response to the user.

    Login or Signup to reply.
  5. 0

    It is always the controller, and it has to be the controller only. It is a basic principle of MVC. You should always hold yourself to the rules and sending response objects through the controller only.

    Login or Signup to reply.
  6. 0

    Something for your knowledge

    In Laravel, we do not need a Controller also. Because they have introduced a mechanism called Route Model Binding, you can return data without controller support.

    Example

    use AppModelsUser;
 
Route::get('/users/{user}', function (User $user) {
    return $user->email;
});

    Other than what I found, this was more accurate and detailed to the Laravel Life cycle hook explaining proper MVC.

    enter image description here

    Hence, when dealing with API(Laravel as API, Vue, React, Angular), we will no longer see View.

    Read

    1. Laravel Request Lifecycle
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search