Newbie Guide on When to use or apply MVC Pattern Technique
Using patterns will certainly increases the complexity of any
software code through additional classes but it helps in
breaking tight coupling.
Something I learn while using MVC is, don’t use it unless is needed.
For instance, the car example from actionscript 3
design patterns (chapter mvc)
If you tried to use MVC on a simple component, it would be:
Model – the properties of the car (car color/rotation/etc)
View – consists of codes that shapes the car, gets data from model.
Controller – consists of codes that changes model data.
When is the right time to use MVC ? (model view controller)
When not to use MVC? (applying KISS – keep it simple)
Before using MVC on anything, ask yourself a few questions:
1. Can the model be used by multiple views?
If the answer is no, just combine the view with the model.
Since the model is only used by 1 view, it is usually takes part
in creating the view (where the model is used to tell the
view on how it should be created)
You need to remember that separating code into different class,
do improve readability but it causes several problems such as:-
(a) the software becomes very complex with many classes.
(b) removing a particular class effects the class that is using it.
Example of model being used by multiple views would be,
a sports car (the model) and the car gadgets (multiple views).
The car will provide the properties (fuel/speed/water) while each
gadgets will keep track one of these properties for changes.
2. Does the model involve in creation of view?
If the answer is yes, just combine the view with the model.
Reason being, the model is only used by that specific view.
For example, the car model provides the width, height, color.
All these can’t be applied for other transportation such as plane
3. Is it necessary to place controller into its own domain?
In most cases such as game programming, the controller
tends to be combined with either view or model.
You can use (view + controller) and (model + controller)
to get the best of both worlds (the advantages)
Separate the controller away from model and view if you see
that the controller can be shared by different view/controller.
This allows code re-usability (save time than coding same stuff)
Controller are usually specific for either model/view.
The more flexible it becomes (in terms of code reusability where
the controller is in its own domain) the harder it would be
generic so that it can be used on different objects.
An analogy would be, car, motorcycle and truck.
The car acts as the generic transportation.
Its much faster than a truck and able to carry more passengers
than a motorbike. Truck can carry twice or more than car, but
slower in speed. The motorcycle is the fastest as it can whiz
through the traffic with ease and arrive to destination faster
than both of them, but carries the least amount of passenger.
To clarify the analogy, the car transport can be shared by
different classes. One class might require speed, the other class
might need to carry stuff. But it does not do them that well.
If you notice that if you use specific transport for a specific
purpose such as arriving to destination fast, then probably you
would choose a motorcycle to whiz through the queuing cars.
It gets the job done better than a car! Truck is similar concept.
Truck does better job in carrying bigger and heavier stuff than
a car. You would need to weight the pros and cons between
these. Code reusability such as the car, you will avoid making
specific code since it can handle both situation good, so you
do not need to make extra code (saves time). On the other
hand, if you make specific code for either the model/controller,
it does the job much better/faster than a generic one since
its customized to do a specific purpose.
An example of how view and model works would be a preloader.
The view shapes how the preloader looks like, the controller
gets information from the model (such as the stage) for total
bytes loaded and current bytes loaded. Then it manipulates that
data into portions to create a smooth progress bar, else the
bar would be jerking as in 1 chunk of load and later smaller chunk.
If we were to place the controller inside the model, this causes
more busy-ness as in the model dispatches event multiple times
for X number of portion divided by the controller. As we know,
flash perform slower in creating objects. the more objects
being created (as in events object created to be dispatched),
the slower it will become.
An example of how model combines with controller would be
a RPG game where you have a character with 4 attributes,
strength, dexterity, luck, and intellect (intelligence).
A user clicks a button (the view component) to request for
weapon damage. The controller in (model + controller) class
will reply to the request by returning the manipulated data.
To calculate the weapon damage, the controller
manipulate one or more of these stats base on the job.
For instance, you are a warrior, your weapon damage is base
on strength and dexterity. So your controller get these 2 data
and manipulate it (example: strength x dexterity x 1.5) and
return these new data back to the view.
Extra MVC Technique Notes
After reading my friend’s opinion on how you use mvc, and another
person’s view on how mvc should work, I understand when to mix
and match them depending on the situation, it isn’t necessary to
stick to one (for example: sticking to view + controller , model)
A simple analogy would be a game such as Desktop Defender.
You don’t use purely rocket towers and pellet towers, but use
a variety of the towers at your disposal to maximize the
efficiency of handling many incoming waves quickly.
A typical multiplayer strategy in any mode would be building
pellet tower first because they are cheap, but once you have
sufficient money, sell those and upgrade to squirt tower as
they have faster fire rate and greater range than pellet
but cost a little more to upgrade. Then switch to rocket
towers for their splash damage and long range, and the list
goes on. As you can see, using different towers at the right
time provides the best result. In case of this game, the
result would be additional points for the time saved by
finishing each monster waves quickly.
In the case of MVC, model + controller (a pellet tower) would
provide flexibility of manipulating the data of the model before
handling to any views. This is to allow standardization of
manipulated data results for all views. For view + controller,
some view wants to have a unique way of displaying the data,
therefore, it has its own unique controller to do it.