Game Development Reference
In-Depth Information
model but rendering information to many unique display surfaces. A view can be
composite, containing sub-views that can each themselves contain sub-views. As
an example, a view could be a tree view that will display hard drive files in a hier-
archical fashion.
The controller is the interface point between the user and the application. The con-
troller reads input sent by the user and instructs the model and view to act according
to the type of input received. As an example, when the user clicks a button, the
controller is responsible for determining how the application will respond.
The model, view, and controller form a triumvirate, so they must reference each
other as shown in Figure 43.1.
Figure 43.1
Common approach to the
Model-View-Controller pattern.
To explain, an event occurs that propagates to the controller. The controller then
changes the model, the view, or both accordingly. If the model changes, events can
be sent to the views; an example could be a request for a redisplay of information.
If need be, the views can go fetch data from the model to display. This pattern
requires that each view must understand the relationship and schema of the model.
It is for this reason that I present a slightly different spin on this paradigm, using
the native event mechanisms of the .NET platform in an attempt to further decou-
ple this excellent pattern from being directly tied between views and model. The
pattern used in this chapter is basically the Model-View-Controller paradigm,
except .NET delegates, and events are used to pass data between model and views.
Such a variation can resemble Figure 43.2.
Search Nedrilad ::




Custom Search