Model View Controller is a common design pattern used in
most applications that have a graphical user interface.
You can use this pattern in pretty much any kind of
application: a web application, a Java application,
a smart phone application, etc. The premise is that
you separate the code for the data model, the actual
interface, and the logic that works behind the scenes.
This allows you to create more modular and re-usable
cold while following the
SOLID principles.
The Model-View-Controller (MVC) Pattern
A standard Graphical User Interface (GUI) has the following functionality:
Allows the user to enter inputs into a program.
Processes those user inputs in some way (e.g. calculations, searching, sorting,
comparing).
Presents meaningful output to the user that contains results of the processing
of the user inputs.
There are three categories of code that make up a GUI in most object-oriented programming
languages:
Presentation code: code that creates the UI components (e.g. text boxes, buttons,
and radio buttons) and lays them out on the screen (layout managers).
Event logic: code that executes when the user manipulates the interface
components (e.g. searching for an employee in an employee list when the user
clicks a "Search" button).
Classes: OOP classes that model data the application needs, such as the
Employee class that models employee records in a database.
Model-View-Controller, or MVC, is the most common
design pattern
used to create GUIs. MVC separates the
presentation, event logic, and classes by defining these three design
components:
Model - the data and/or object/classes that model that data.
This should be code/classes that are independent of the rest
of the components. You should be able to use the model in
any application.
Models data, nothing else! There should be no other code/logic
in the model.
View - displays data/output to the user, provides a means for the
user to manipulate the data, etc.
Views are specific to the model they're allowing a user to manipulate.
There are often multiple views on a single screen (the view is not necessarily
the whole screen: a button is a view, a text field is a view).
Controller - the code/logic that executes behind the scenes
Each View is paired with a Controller; they stay in sync with each other.
The controller interprets user actions on the view, such as button clicks
or typing in a field.
Views send user inputs to the controller, and the controller processes those
inputs.
The controller sends outputs back to the view so the user can see them.
Model-View-Controller
MVC is actually the design pattern used in web applications today:
Model: the HTML code, which defines the structure and content of the page.
View: the CSS code, which defines the formatting and layout of the page.
Controller: the browser, which provides a means for the user to manipulate
the elements on the web page.
An example of MVC used in Java:
Model: An Student class that models a student in a college. Students
have an id, first name, last name, and Contact information. Students
can register for courses and receive grades.
View: The UI that allows a registrar clerk to update the student's
personal information, select the courses for which the student wants
to register, and enter grade data for transcripts.
Controller: The Java code that retrieves Student data to display on
the View, updates the Student information when the clerk enters a grade
or registers the student for a course, and displays information about
a Student object on the View.
The idea behind MVC is that it allows you to create modular and re-usable
components. For example, you might create a UI that allows a user to
enter data for players on their fantasy hockey team. You would likely
have a Player class that models a single player. You can re-use that
Player class in several applications. You could even use the Player UI
in other applications that needed to provide a means to input player
information. You can also re-use the UI in different parts of the
application: not just to input player data, but also to search for
or edit player data. By separating the event logic (validate player
input data, use data to construct a player object, save a player
object to a database, get a collection of players, get a single
player by jersey number, etc) you can use that same UI for several
different functions in the application.
Exercise
Imagine an application where you'd like to sell a specific
product (whatever you like). Think about the part of the
application that allows a customer to search for a product
by description and view the matches from your catalog.
Model: Create a UML diagram (or simply list the data members
and methods) of a class that would model an inventory
item in your catalog.
View: What user interfaces would this part of your program
require? Create rough sketches of those UIs.
Controller: What kinds of functionality is your program going to
need? Describe each function. Which functions will need
to acces the view(s)? Which functions will need to access
the Model?