MVC Really a Four Headed Pattern?

Is it just me or is MVC really Model-View/Cont开发者_运维知识库roller-View View-Model/Controller-Model with two distinct controllers? alt text http://www.hupcapstudios.com/projects/mvc/mvcvmc.gif

---

They are all just flavors of the Mediator pattern as opposed to first class patterns anyway. As such, it's probably okay for two distinct flavors to have two distinct names.

---

I consider these patterns to be loose guidelines more than strict patterns. I use a lot of MVVM (introduced in WPF but works great with anything that supports a good 2-way binding framework), and I always see some kind of controller (or controllers) being used with it. Every project is different and has different needs based on size, purpose, etc.

---

I think that it often has two models, the base model model and the view-model, but it typically just has one controller.

---

Better to change the moniker to something more accurate

Algorithmic code, IO code , Initialization/Runtime Management code, Error/Interrupt code, Event/Messaging code.

or User input/output code, internal housekeeping code, data-centric code, program state code.

MVC has the unfortunate viral effect on code systems of enforcing its rigid model upon all design of operations in a codebase. That is why Professors of CS, and Vendors of model-driven software like it, not because it is superior to this or that paradigm. The separation of duties allows for cleaner modeling and revision at the planning stage, and is fantastic for designing a database, but is not the correct tool for every programming task. Highly inter-relational event-based programming (games, robotics, guidance) lends itself to messaging paradigms with a central message controller, but data views may or not be required for the interactions to take place. Code reuse is the defining reason for wanting MVC , so that all views can be attached to all models with a single controller object. This is silly in a lot of cases. True OO would dictate that each object know how to view ( perform IO ) on itself. Pure MVC would be that model objects would have no clue about IO or what they are being used for, and the Controller manages it all, creating views for each object. But nothing is pure and there is a lot of messaging between all three kinds of objects. plus there is in most computer languages things that are objects and things that are not objects, and different ways of modifying each. MVC has an earlier ancestor which all books assume that you are clued in to: the basic INITIALIZATION, INPUT, STORAGE, PROCESSING, OUTPUT, FINALIZATION model, which of course no program could exist without following. Get the above 6 right and it doesn't matter if its procedural, MVC, Event based, or spaghetti.
It does make a difference in the sequence: define Problem Domain, Design Solution, Implement, Debug, Redesign, Test/Debug loop, Deploy , Maintain/Modify loop.

MVC is more of an interfacing methodology for objects into a system than a "Better Way to Program". It is by nature a hierarchical system with the controller at the top, when the real work is done by the algorithmic code. Perhaps a better model for some tasks is to have the model be its own controller and deal directly with IO code (views) instead of a Middle tier of object handling.