ITE 2200 – Business

Application
Programming
Introduction To The Model View Controller Pattern
Model and Databases
Presented By
Owen Grant
Outline
What is the Model View Controller?
• The MVC is a design pattern used to structure a programme such that
there is a clean separation between presentation (view), business logic
and data (model) and a mediator between the two (controller).
• It divides your application into three layers and decouples those layers.
• Makes it easier to create loosely coupled OO programmes.
• Each layer of the MVC has a clear and well defined purpose.
• The MVC is considered and architectural pattern, therefore, while the
general idea will be the same across all projects, implementations may
differ depending on the use case.
General Idea of the MVC

• The controller acts as a mediator between the model and view.

• Changes made to the model that did not originate from the view or controller are sent as notifications to the
controller which then updates the view. In this case the change to the model might have originate from
another part of the application.
• This approach is usually used when the view is a direct representation of the model or when the application is
structured in such a way that each view is mapped by one in-memory model. Example, drag and drop user
interface builders.
Model
• Contains all the code needed do the business logic of the programme.
• Contains all database access, etc.
• Contains all domain models.
• May have a reference (direct access) to the controller.
• Must be completely unaware of the view.
• The model in the MVC is not the data model of your application. The data
model are basically objects that are used for passing messages to various
parts of you business logic.
• The model includes both your data model and business logic.
• Model = Data Access + Data Transfer Objects + Business Processing.
View
• Gets user inputs.
• Displays data to the screen.
• Clueless as the structure of the model.
• That is about it.
Controller
• Mediates between the view and model.
• Implements the methods needed to respond to view events
(response to user click, etc.)
• Controller Flow-
1. Takes data from the view layer
2. Call operations from the model layer
3. Uses the data returned by the model layer to update the view layer
• Alternative Flow
1. Receives notification from the model layer
2. Updates the view with the data from the notification
MVC 1 Example (Gluon
SceneBuilder)
The Good About MVC
• Loosely coupled layers allow changing the implementation of a layer
without breaking the application.
• Faster development can be achieved with teams by having sub-teams
working on each layer.
• Being model agnostic at the view layer makes it easier to create
multiple views for the same model.
• Easy to understand
The Bad About MVC
• Can result in cluttering of controllers with very large applications.
• The decoupling to the model from the view results in extra code
within the controller for passing data between the two.
• The levels of indirection may too considered over engineering for
some small projects.
• The responsibility is on the programmer to ensure the current state of
the model is represented in the view. In other architectures such as
the Model View ViewModel the synchronization between the model
state and the view is inherent.
Developing the Model
• The components which make up the model will vary based on the use
case. In general the following are present -
• Data[base] Access Class
• Data Access Objects (DAO)
• Data Transfer Object (DTO)
• Business Logic
Data Transfer Object (DTO)
• Simple objects used for moving data around your application. In this
case the Model.
• Does not contain any business logic.
• Contains properties with getters and setters.
Data[base] Access Class
• For some applications, the data[base] is abstracted by a single class.
• This data access class does the following –
• Manages data[base] connections.
• Runs data[base] queries.
• The method is suitable for application with a small-moderate amount of
data access.
• The abstraction separates the data[base] implementation from the rest
of the application. This means you can change the underlying data[base]
without changing the rest of the application.
• Encapsulates the data source from the rest of the application.
Database Access Class and DTO
Data Access Object (DAO)
• Very similar to the Data[base] Access Class.
• Instead of a single Data[base] Access Class, we create a Data[base]
Access Class for each Data Transfer Object.
• Scales well as your application grows.
• This additional layer of separate can reduce the complexity of
development by restricting the data access API available to the
different parts of you application.
• Using a DAO as a Data[base] Access Class is a bad application “smell”
Business Logic
• All the code in your model that implements business processes.
• Where your functional requirements are implemented.
• Not hard to understand.
• Very straight forward concept
• I don’t see how you can possibly get this one wrong if it comes for
test.
• It is coming for the test.
• Don’t get it wrong.
Model Overview
Connecting to a Database
• In general, the following are needed to connect to a database from
your application. This may differ when using embedded databases.
• Database Management System
• Database Service Hostname
• Database Service Port
• Database Name
• Database Driver
Connecting to a Database
• Database Management System – The database your application uses
to store information is provided by an application as a service. This
application is called a Database Management System . This
application –
• Hosts multiple databases
• Manages connections to the databases.
• Provides for create, read, update and delete operations on databases.
• Database user access control
• And a whole lot more that you should research. Hint, explore PhpMyAdmin
Connecting to a Database
• Database Management System Hostname – this is the label assign to
the node on a network where the DMS is located. Example localhost,
or some IP address or just some service hostname (anything you
want).
• Database Management System Port – the port number the DMS is
listening on for communications.
• Database Name – A DMS provides access to multiple databases.
When connecting to a database, the name of the database must be
specified. Similar to the SQL USE command. Example Use
SchoolDatabase;
Connecting to a Database
• Database Driver – this is a database client library which encapsulates
the low-level communication with the database and allows you to run
commands (SQL, or Domain Specific Language (DSL)) against a
database. This library is used by applications which interact with
databases. Does the same job as a driver on your computer.
 Next Class Will Be
Strictly Implementing
The Model
References
• https://mdn.mozillademos.org/files/16042/model-view-controller-lig
ht-blue.png
• https://cdncontribute.geeksforgeeks.org/wp-content/uploads/MVC-D
esign-Pattern.png
• https://www.dummies.com/web-design-development/mobile-apps/t
he-model-view-controller-mvc-design-pattern/
• https://www.ibm.com/support/knowledgecenter/en/SSZLC2_8.0.0/co
m.ibm.commerce.developer.doc/concepts/csdmvcdespat.htm
• https://www.geeksforgeeks.org/data-access-object-pattern/