MVC - 3 : The Execution

The Execution

We've already covered some of the nuances in the Concepts section above, but there are many more. Let's briefly take a look at three, data propagation, identity maintenance, and multi-model mvc.

Data Propagation

The data most frequently flows like this: Action by User --> View --> Controller --> Model

or, if the user isn't acting and there is a Controller running on a loop: Loop --> Controller --> Model.

How does the View ever know that the Model has changed? There are two ways. The first is that whenever a property changes within a Model it broadcasts an event that the View is listening for. The second is that there is a Controller constantly looping telling the View to go look at the Model. There are reasons both of these are good and reasons both are bad. The event based version uses less processor when nothing is happening, which is great. Users will appreciate that when they are running your program that there computer doesn't go to it's knees as your program sucks up all it's resources. The Loop version however allows all pieces of a program to update at once. This allows for synchronization. This becomes more important in more complex programs, but requires more processing power.

Identity Maintenance

The Model, Controller and View all need to maintain their identities or separation goes away, and then all the trouble you've gone to in order to create Models and Controllers and Views and wire them all up is for nothing. So, the Model should only contain data (and in the case of the event version, discussed above, dispatch events when those pieces of data are changed). The Controller should be the brains. The Controller can look at the Model, modify the Model, and in more advanced MultiMVC programs actually look at child Controllers and Models and their events. The View should do one of two things (or in some cases both), receive user input and send it to it's Controller or display the state of it's Model. In fact, most programs should be able to be coded so that the Models and Controllers can exist without any need for a View.

Multi-MVC

The Multi-MVC is one in which there are multiple Models. There are often multiple Controllers or multiple Views, but when there are Multiple Models working in concert, you have a MMVC. For now I will only display the event version. Looking at it's creation path, storage path and event propagation. In all examples remember that the Model and Controller don't need the View and should be thought of separately from it.

Creation Path

The Creation Path shows who creates who. Initially the Program creates M1, C1 and V1. Then C1 creates both M2 and C2, and then C2 creates both M3 and C3. So, in this way Controllers are once again the brains. The Controllers make each deeper level of Models and Controllers. But what about the Views? V1 creates V2 which creates V3. In this way the View creates any of the components that it needs and it's child Views create any of the Views they need. But don't the Views need to know about their corresponding Models and Controllers? They do! Let's take a look at how they're stored.

Storage Path

Storage is the sibling of creation. C1 created M2 and C2, but it stores them in M1. So, M2 and C2 are properties of M1. Much like say checkers are pieces on a checker board. V1 contains V2, just as the visual representation of the checkboard would contain the visual representation of the checkers. This brings us one step closer to how the child Views know about their corresponding Models and Controllers.

Event Propagation

Okay, this is where it all comes together, so let's take it one step at a time. V1 listens to all events that come from M1. So, anytime any of the properties of M1 change V1 knows about it. So, when C1 adds M2 and C2 to M1, that's a change! M1 dispatches "hey I've got new Ms and Cs!" V1 hears this and looks at M1's properties and sees M2 and C2. V1 creates V2 and gives it M2 and C2! WOW!! They're all tied together now! BUT the Views were created separately from the Models and Controllers!

So, as you can see everything is not as simple as it looked at the beginning and quickly gets complex, but if you follow these templates above you can have successful MVC or MMVC programs.

Thanks,

GT