In MVC, the view component doesn't receive user input directly, but the controller component does.

When the view component creates a view, does the view component deliver the view to the user directly, or does the view component send the view to the controller which then delivers the view to the user?

Are the answers the same when the application is a web application or a desktop application?

When the application is a web application, are the answers the same when MVC is on client side or server side?


  • 1
    You may find this interesting: The Best Refactoring You've Never Heard Of. For a nugget of the difference between web and desktop: you "cannot" send a function over the network.
    – Theraot
    Commented Dec 1, 2019 at 7:51
  • 2
    The first thing to realize is that Server-side Web MVC (e.g. ASP.NET MVC & similar where controllers handle requests and views render to HTML) is not the same as client-side/desktop MVC/MVP UI pattern. In the UI pattern, generally the View component is the view (it doesn't create one). Also modern view widgets have the capability to detect user input, back when MVC was first created, widgets had no such capability (they were just pictures on the screen), so every widget had it's own MVC, where C handled the input - in modern MVC, C implements the nontrivial behavior of a larger view. Commented Dec 1, 2019 at 10:12
  • @FilipMilovanović Thanks. What is a "view widget"? Is it used in sever side web MVC or client side MVC/MVP? Could you be specific about why and how "Server-side Web MVC (e.g. ASP.NET MVC & similar where controllers handle requests and views render to HTML) is not the same as client-side/desktop MVC/MVP UI pattern"? Maybe in a reply? I always upvote replies. softwareengineering.stackexchange.com/questions/403332/…
    – Tim
    Commented Jan 4, 2020 at 22:46

3 Answers 3


MVC is a pattern, and works the same on desktop, mobile, websites, client, server - whatever implements the MVC pattern tends to follow the same general process (that's why it's a pattern). It just so happens that it's a particularly good fit for the http protocol, so that tends to be where it has the most traction.

The View is used to present the caller with some information. In the case of a website, this can be an html, web page with data. For an API, this can be JSON data without the html, etc.

When the caller submits a request, be it GET, POST, PUT, etc - that request goes to the controller. Sometimes it has data associated with it (POST bodies, or a querystring on a GET request).

The controller is the main player in MVC. It receives the request from the caller, determines what to do, and should ultimately return a view (e.g., some data, or page markup, or something back to the caller. To be clear, it's the controller's responsibility to make sure that view gets sent to the caller. (Your question of whether it's direct or indirect I don't quite understand: the controller shapes the result/view and sends it along, so direct, I guess that'd be)

It may help to think of it as a request/response pair. The request goes to the controller, and the response from the controller is the view. (The Model portion of MVC is a somewhat ambiguous term and usually means whatever data structures you might need to work with in order to perform the requested action and/or shape the response data)


When the view component creates a view, does the view component deliver the view to the user directly, or does the view component send the view to the controller which then delivers the view to the user?

In truth, the controller does not need to know where the view is going. Ideally, a request is mapped to the controller (the router does that), and the controller constructs the response, I mean, the view. I'm ignoring model.

I am describing an interface. The controller has an interface that takes requests and return responses.

There can be steps between the controller returning the view and it reaching the user. For example, it can be placed in a template, it can be gzipped, etc... the controller is – ideally – unaware of that. Which also makes the controller easier to test.

Oh, and on the client, the response will probably be taken by a service worker, which will do dynamic caching – and perhaps other stuff too – before the user can see it. In fact, when the client makes a request, it goes to the service worker (unless there isn't, or it is being bypassed), which can return from cache, build a response or ask the server.

Are the answers the same when the application is a web application or a desktop application?

As you have seen, the way MVC is used has evolved. Let me put it this way:

  • MVC pattern. It has always been the same, since its inceptions in Smalltalk. It is, arguably, the oldest named pattern. It can be used once or multiple times per application.
  • MVC architecture. Reinvented each decade, using the MVC pattern in a slightly different way. However, it is always an architecture, it dictates how you organize your code around it and takes center stage.

In the 80's, soon after its inception, the MVC pattern was used to control individual components in Smalltalk. In the 90's it was used to handle whole pages/form/reports instead of components. As replacement, we shifted to the concept of widgets. Then, in late 00’ it got to the web.

I mentioned in another answer the big scary thing called "Internet" that breaches the architecture. If you want to put code on both side of an IO device (the network), you got to shape your architecture to that. That restricted the way MVC is used on the web.

Thus, yes, it is the same MVC pattern. Not necessarily the same MVC architecture. In the desktop there is much more freedom of how you do things.

Today, MVC on the desktop is not that common. Instead the most common paradigm for desktop continues to be forms and widgets (perpetuated by visual tools). A form is a view class, it takes input from the user (via the operating system), it has a model of the view (the widget tree), and there are event handlers. I suppose the event handlers can be considered controllers... they ought to manipulate the widgets to update the view. Here the controller does not really return a response.

It can be a mess, you would not only have controllers and view in the same class, which can be consider a mix of responsibilities. Beginners also have a tendency to mix responsibilities in other ways: for example having an event handler talk to both the database/file storage and the widgets.

However, you could do something closer to MVC in the desktop. Baring going back to the old ways, we can apply it similar to how it is used in the web.

For example, in one of my projects I have a form that is only for controlling what is being presented in another form (which is intended to be in a separate display). I have a type that represent what is presented in the output form. The control form takes input, calls controllers that transform the data, and then the result is sent... actually it is sent two places. What handles how to show it is a custom widget, not the display form. Which also allows me to put one widget to show a preview in the control form and another to show a full size in the display form. So, yeah, the view does not go directly to output. Well, depending your definition of “directly”.

The claim that MVC fits the web comes from the fact that you are expected to return a full page to the client. That is, you cannot update individual components of the web (well, OK, you could, with a frontend framework, but not out of the box), and thus you want a complete view constructed and returned. Remember that in Smalltalk MVC was for single elements. That way to use MVC does not fit well the web.

The frontend, instead of taking a request as input, takes events from the browser. And instead of returning a response, it manipulates the DOM. We can have MVC there. And we can have MVC on the server too, at the same time.

In fact, let me tell you that building a Web API first is gaining popularity. The view can be a json document. You can build a frontend with framework around that... However, who says the client has to be a browser? I would have a desktop application connect to the Web API, for example. And sure, use MVC on the desktop, why not? Have MVC on the desktop and on the server, and the same time.

There are many ways to apply the underlying pattern of MVC. It is the same idea, independently of where you apply it. Yet, the way we apply it has changed, and every time they call it "MVC", and literature is written about how MVC (the architecture) works, usually ignoring its history, and the other ways it can be used (because they are talking about the architecture, not the pattern).

  • Just wanted to say: A front end MVC framework is essentially a variant of desktop MVC (assuming it runs on the client), except the platform is the browser, so it makes use of HTML & DOM. Commented Dec 1, 2019 at 10:23

The MVC does not take into account the network distribution of the components. It was initially developed for integrated applications in mind:

  • It can be easily adapted for distributed applications, when the model is on a server (served over a nice API) and view and controller on the client.
  • But when a remote controller runs on the server, how can it take user input since the users are on the client side ? If you consider the web pages on the server as the view, what would be the javascript that rungs on the client side ? How could the controller create new additional views on the client ? All this would require a controller proxy on the client and it's then no longer a true MVC.

It is exactly this thought that led Talligent invent the MVP model in 1996. In this seminal paper they explain in detail the network distribution issues of traditional MVC and show how transforming the C in a P cleanly solves the client-server requirement, the P being the middleman, that can be split between a client and a server part if needed.

Conclusion: MVC is great. Its biggest advantage is according to Martin Fowler the separation of the Model from the UI that is very helpful in client/server. But if you can't rely on a rich client, and have to distribute View and Controller between client and server, then gain some time and go for MVP in order not to reinvent the wheel.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.