Datasheet
DESIGN PATTERNS IN WEB FRAMEWORKS
x
15
‰
Model — Represents the business logic of the application. It is more than just the raw data;
the Model has to represent the structure of data with all relationships and dependencies. It
may comprise one or more classes that correspond to logic objects of the application and
provide an interface for manipulating them. The Model is the only layer that uses persistent
storage. It should completely encapsulate all database connections. The model should also
notify the View when its internal state changes, so the View can be refreshed.
‰
View — The output displayed to the user. The most important thing is that the View never
modifi es the application data; it only presents it. There may be multiple Views for the same
data, such as traditional HTML, PDF, Flash, or WML for mobile devices. They should be
interchangeable without modifying the other layers.
‰
Controller — The part of an application responsible for handling user interaction and taking
all other actions. The Controller should be created with simplicity in mind — it should be
the controlling part that uses methods provided by the Model and the View; it shouldn’t do
everything by itself.
Figure 1-17 illustrates the relations between the three layers.
View
Result
Delivers
Data
Model
Controls
Controller
Data Manipulation
Action
FIGURE 117: Model-View-Controller pattern
MVC versus MVP
MVC is an old design pattern, dating back to the 1979 work “Applications Programming in
Smalltalk-80: How to use Model–View–Controller.” by Trygve Reenskaug. Since that time, it was
often used in non-web applications, mostly graphical user interfaces in compiled languages like
C++ or Java. There it was easy and natural to implement an exact MVC pattern, but for web
applications, it was somewhat modifi ed.
Model-View-Presenter (MVP), shown in Figure 1-18, is a derivative of MVC. It is a three-tier appli-
cation structure, where the Presenter acts as a middle layer between the View and the Model. The
Presenter differs from the Controller in that it loads data from the Model and delivers it to the View.
Most so-called MVC frameworks follow the MVP pattern. While it is not bad itself because MVP
seems even better suited to the task, this naming convention may be somewhat confusing. As long as
MVP is derived directly from MVC, it is not a big problem, so in this book we will follow the names
c01.indd 15c01.indd 15 1/24/2011 5:45:18 PM1/24/2011 5:45:18 PM