I think the main point is what MVC is trying to achieve, and it had better be a real world problem or it isn't worth achieving it. I think the real world problem is that, prior to using MVC separation of concerns, changes in the user interface used to require changing the model and the controller. By using MVC you break the dependency that MC have on V, but it doesn't matter if V has a dependency on MC because it really only exists to render aspects of MC. For example, we have successfully experimented with swapping a windows front end with a web front end. Both the windows and web front ends (V) depended on the M and the C (which made them easy to code) but the M and the C were able to remain unchanged in both instances. So basically MC is the bit you want to keep stable and V can change (as they often do). Separating M and C also achieves other 'real world' goals of allowing elements of the solution to vary independantly of each other. Any separation of concerns adds complexity and should only be done for a real reason. Hope that helps Andrew