Fig17.
Model-view-controller
Participants & Responsibilities
It was originally applied to map the traditional input,
processing, and output tasks to the graphical user interaction model. Thus, it
is straightforward to map these concepts into the domain of multi-tier
enterprise applications.
§ Model - The model represents data
and business rules that govern access to and updates of this data. Often the
model serves as a software approximation to a real-world process, so simple
real-world modeling techniques apply when defining the model.
§ View -The view renders the contents
of a model. It accesses enterprise data through the model and specifies how
that data should be presented. It is the view's responsibility to maintain
consistency in its presentation when the model changes. This can be achieved by
using a push model, where the view registers itself with the model for change
notifications, or a pull model, where the view is responsible for calling the
model when it needs to retrieve the most current data.
§ Controller - The controller
translates interactions with the view into actions to be performed by the
model. In a stand-alone GUI client, user interactions could be button clicks or
menu selections, whereas in a Web application, they appear as GET and POST HTTP
requests. The actions performed by the model include activating business
processes or changing the state of the model. Based on the user interactions
and the outcome of the model actions, the controller responds by selecting an
appropriate view.
Strategies
Web-based clients such as browsers. Java Server
Pages (JSP) pages to render the view, Servlet as the controller, and
Enterprise JavaBeans (EJB) components as the model.
Centralized controller. Instead of having multiple
servlets as controllers, a main Servlet is used to make control more
manageable.
3.3.1.2. DAO
We use a Data Access Object (DAO) to abstract and encapsulate all
access to the data source. The DAO manages the connection with the data source
to obtain and store data.
The DAO implements the access mechanism required to work with the
data source. The data source could be a persistent store like an DBMS. The
business component that relies on the DAO uses the simpler interface exposed by
the DAO for its clients. The DAO completely hides the data source
implementation details from its clients. Because the interface exposed by the
DAO to clients does not change when the underlying data source implementation
changes, this pattern allows the DAO to adapt to different storage schemas
without affecting its clients or business components. Essentially, the DAO acts
as an adapter between the component and the data source.
Structure: Figure18 shows the class diagram representing
the relationships for the DAO pattern.
| 
