Can we say that MVC is subsystem (or subset, sub-architecture) of client-server architecture?
4
-
4This will be most likely closed as unclear or opinion based. Anyway, basically no. Client server is a network architecture. MVC is a a pattern in software architecture that doesn't even require to run on a client server architecture (you can use it to write a purely single user desktop app where everything runs on a single local machine). So both have not really much in common even if it may look so because MVC became popular in web programming.– thorsten müllerMar 31, 2016 at 8:42
-
4Personally, I think this is perfectly answerable and does not need to be closing. What thorsten just said basically is the correct answer, namely that "MVC" has nothing to do with clients and servers so the two terms are orthogonal. You'd have to be very confused about what MVC is or what clients and servers are to disagree with that.– IxrecMar 31, 2016 at 9:01
-
6@Ixrec I see a rise of a new genre at Programmers, let's call it beating a straw man. Someone dumps a question with a simple but terribly misguided / flawed assumption and answerers pile on it competing who would be the best in trashing it. This genre will definitely be popular (as it's essentially a sub-genre of bikeshedding). And it will be widespread because it is dead easy to construct such strawmans to beat– gnatMar 31, 2016 at 9:13
-
2@gnat: Do you have any evidence for this rather sensational claim?– Lightness Races in OrbitMar 31, 2016 at 11:22
Add a comment
|
2 Answers
No.
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.
answered Mar 31, 2016 at 11:22
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
- ...etc.
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.
answered Mar 31, 2016 at 12:05
