Can we say that MVC is subsystem (or subset, sub-architecture) of client-server architecture?
MVC relates to the design and structure of an application as it pertains to the internal flow of data, and the eventual presentation of that data.
It is entirely orthogonal to whether that application is a server, or is a client, or is both a client and a server.
MVC is a UI design pattern which stands alongside other equivalent design patterns such as MVP and MVVM (note:, by "equivalent", I mean only that they accomplish a very similar goal, however they accomplish that goal in very different ways).
One thing that all those UI patterns have in common is that they simply describe the structure for a UI application (Which may also depend on your choice of UI framework - some frameworks lend themselves to particular patterns by providing you with some of that 'glue' out-of-the-box).
The resulting applications built with those patterns may or may not be networked; none of those patterns have anything to do with networking or client-server architecture. There are other patterns for that kind of thing.
The Controller and View portions of MVC relate to the way in which UI logic is separated from Appearance and Layout of a UI, whereas the Model is "everything else".
Views should generally be dumb - being a concrete visual representation of everything the user will see and interact with. Views generally contain no logic whatsoever. Views typically describe (among other things) widgets, colours, fonts, images, text, layout, as well as simple bindings to a controller.
Controllers are a more abstract representation of the UI with no visual components. They tend to be closely related to (but not dependant on) the View. Controllers are intended for UI logic while also being agnostic to (decoupled from) the concrete view.
A Controller should know what to do when a button is pressed, however that controller should have no knowledge of that button or any other widgets. It will be responsible for logic for inbound UI events such as mouse/button clicks. It should also handle the logic for modifying the state of a view - such as deciding when to enable/disable a button, or when to show a message to the user. Again, it shouldn't have any specific knowledge about those widgets, it will only be responsible for the logic (i.e. making the decision about if and when something on the UI should change).
Due to the implied relationship between a View and Controller, it's common to see them existing in-tandem - i.e. one controller for every view, and one view for every controller. (However that's not mandatory, just a common convention).
The Model portion of MVC is an umbrella term meaning 'the rest of your application'.
Model(s) could contain any or none of the following:
- Networking code (which may include client-server code, or messaging)
- Database / CRUD operations
- Wider application logic
- Domain objects / Business objects
- File Handling
- Diagnostic logging
- Any code to interop with some other platform
If your application is part of a wider system, the model is probably part of your Application layer. In a small self-contained application, the model may be your main Business Logic Layer. In extremely small and simple applications, the Model may even just be your Data Layer.
Models should be totally agnostic to Views/Controllers - a Model should be unaware that its being used for a GUI application; so there tends to be little or no relationship between the number of Models in an application compared to the number of Views/Controllers. Models represent the real 'work' and contain the objects/entities which actually make the application do all of the things it needs to do.