Java Reference
In-Depth Information
■
Note
It is possible to consider the counter person as part of the View, since they are asking the customer
questions and possibly requesting payment for the meal. However, for the purposes of simplicity, we are
ignoring the multiple roles the counter person may play.
It is the Controller's job to handle the actual details of getting the meal for you, and you do
not need to see or understand how they get your meal. The Controller may go to the kitchen
and ask the chef to prepare your salad and milk shake, or the Controller may have to ask two
separate people to do these two tasks. The fact is, when you order your food, you never go in
and tell the individual employees to go off and make your meal, and you certainly do not pre-
pare the meal yourself. Organizing the supply of food is the job of the Controller, and all you
care about is getting the next View (the meal itself ).
The next component of the MVC is the Model. In the fast-food example, the Model is the
kitchen. The kitchen will provide the various Views—the standard menu, any “specials of the
day” menus (which might be listed on a separate page on the menus used inside the restau-
rant, or on a blackboard for the drive-through customers)—then take the order and present
the data (the food) for the next View.
Benefits of MVC
The main benefit of the MVC pattern is the abstraction of the data presentation from the sys-
tem operations. The implications of this fact are many. For example, if a system must display
data to many different output methods, this pattern is the ideal solution. Under the MVC pat-
tern, the data model remains the same, but the method of display can very easily change.
Thus, the same system could have a GUI front-end and a web-based HTML front-end, all
without any changes to the rest of the system.
The MVC pattern also helps limit the scope of changes to a system. The majority of the
time, a client will get preoccupied with the functionality of the presentation tier. This is quite
understandable, considering that this is the portion of the application the end user will actu-
ally use. Many times, clients will request numerous changes to the front-end design. The MVC
pattern limits the scope of these changes and often precludes them from impacting other por-
tions of the system. This is not to say that the MVC pattern makes system updates a snap, but
it certainly does make the front-end of the system much more flexible.
Drawbacks of MVC
Everything has a good side and a bad side, and the MVC pattern is no exception. MVC is not
the best option for every system. For instance, a system that does not need the capability to
display data through multiple sources may not be a good candidate for this pattern. MVC does
employ a large amount of data abstraction, and sometimes the associated overhead is not
worth the cost, both in development time and performance.
The MVC pattern is generally a good idea, and it is one of the more lightweight design
patterns. It is also widely used, and is supported by most development platforms. Its useful-
ness almost directly correlates with the size of a project. If the development task requires
