3 ms·
Good point, but I think you’re thinking too much about the single client case. Consider if you have an application that serves multiple clients at the same time
by ezyang 16y ago
Good point, but I think you’re thinking too much about the single client case. Consider if you have an application that serves multiple clients at the same time: the side effect of the view model is no longer “update a screen” or “play a sound through a speaker”, it’s “update screen X” or “play a sound through user X’s speakrs.” You can make a case for making this logic live in the logic, but it should start making you itchy, and I think this sort of routing functionality should live in the controller. In which case, your life is a lot easier if the View is pure.
- Chris_Newton 16y agoI'm sorry, but I don't see how what I described is limited to a single client. There is no reason you could not have your model running on one machine, and a view/controller pair running on another. If you have multiple clients, just start a view/controller process on each of them. Indeed, I have worked on systems with essentially this architecture, and it works fine. Fundamentally, MVC is a three-way relationship, designed to support an interative user interface. I don't see what is gained by trying to shoehorn a web-based system with a linear structure into those boxes. It's not wrong, it's just different, but it is unhelpful to call something different by the same name. Funnily enough, the MVC idea does work rather well for the client side of a web-based interface, as the event model in JavaScript lends itself quite neatly to handling by a controller, and the whole HTML/DOM set-up lends itself to rendering by a view.