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).
