Infrastructure

In one language called Structs - one can imagine virtual girders supporting platforms of functionality, with all sorts of connection between levels. Important packages - like people - tend to move via elevators (slow, safe, secure, private) where as documents can be seen as you walk through offices - the intelligence of running an office has little actual cost as it appears and scrolls on screens (fast, public, usually accurate but sometimes breaks). The office models of why structure is important in software. You want to apply appropriate rules to different objects depending on what floor they originate, and what their purpose is. The number of rules and attributes that attach to a single document (entity) increases as new routes and other people's requirements are added. The superhighway and its public nature sounds simpler, but in fact has to accomodate millions of users - therefore it has to have far more going on for it to be able to cope. Elevators, in contrast, have both imposed and real limiters both in capacity and rate of transmission.

In a MVC environment there is a greater rigour to the separation between the display and the detail. The flash and the function are created by opposing skill sets - it is only natural that MVC and OO evolved the way they have - are they the best idea yet? Maybe.

MVC

When the software has a set of ideas imbedded in them and expressions can be by linking together lots of independent system calls which can take their time, programmes no longer are being executed in strict orderly fashion, they are being executed on demand.

With all resources ready and waiting for the interactions that reach instances of them from connections to browser sessions there are many things going on. There is an interaction of the database MODEL with memory of the computer. In a monolithic system each instance is of course huge. In an efficient multitasking system, only those processes which must be done in a sequence are at all complex. Everything else is broken down into the specific bits of code and data that need to be present to support the action request from the CONTROLLER.

Now we are talking about the engine side of the equation. The driver (user) still needs to see a representation of the model, as filtered through the processing of the controller. We put the VIEW on a screen. The VIEW is intimately connected to individual parts of the MODEL via the CONTROLLER.

Rarely, although it is possible - does the VIEW get data direct from the MODEL. In fact to do so defeats the very advantage we obtain by disconnecting them completely. The real strength of this triangle is the isolation it achieves by running discrete processes that only contain those portions of the MODEL it affects and all the logic that it requires. In another task segment, is another MODEL/VIEW/CONTROLLER.

The benefits of this arrangement are fairly evident. They are obvious. The are also discrete and non-obvious. And that is there the real benefit lies. In the quality of the engineering of the engine.