Transcript Intro To MVCx - American University of Nigeria

Developing Web-applications with
Grails framework
Presented by Alexey Vedishchev
Intro To MVC Architecture
American University of Nigeria, 2016
2
Design Patterns
• The hard problem in Object-Oriented
programming is deciding what objects to
have, and what their responsibilities are.
• Design Patterns describe the higher-level
organization of solutions to common
problems.
• Design patterns are a major topic in O-O
design.
3
The MVC pattern
• First Appeared Formally in:
“A cookbook for using the model-view
controller user interface paradigm in Smalltalk8”
by Glenn E. Krasner and Stephen T. Pope
Journal of Object-Oriented Programming,
1(3):26-49
August/September 1988
4
The MVC pattern
• MVC stands for Model-View-Controller
• The Model is the actual internal representation
• The View (or a View) is a way of looking at or
displaying the model
• The Controller provides for user input and
modification
• These three components are usually
implemented as separate components of
program.
5
The Model
• Most programs are supposed to do work, not just
be “another pretty face”
▫ but there are some exceptions
▫ useful programs existed long before GUIs
• The Model is the part that does the work--it
models the actual problem being solved
• The Model should be independent of both the
Controller and the View
• But it provides services (methods) for them to
use
• Independence gives flexibility, robustness, etc.
6
The Model
• Most programs are supposed to do work, not just
be “another pretty face”
▫ but there are some exceptions
▫ useful programs existed long before GUIs
• The Model is the part that does the work--it
models the actual problem being solved
• The Model should be independent of both the
Controller and the View
• But it provides services (methods) for them to
use
• Independence gives flexibility, robustness, etc.
7
The Controller
• The Controller decides what the model is to do
• Often, the user is put in control by means of a
GUI
▫ in this case, the GUI and the Controller are often
the same
• The Controller and the Model can almost always
be separated (what to do versus how to do it)
• The design of the Controller depends on the
Model
• The Model should not depend on the Controller
8
The View
• Typically, the user has to be able to see, or view,
what the program is doing
• The View shows what the Model is doing
• The View is a passive observer; it should not
affect the model
• The Model should be independent of the View,
but (but it can provide access methods)
• The View should not display what the Controller
thinks is happening.
9
Architecture Diagram
Model
business logic
Get
State
Event
View
model representation
Set
Update
User
Actions
Change
View
State
Controller
user interaction
10
Combining Controller and View
• Sometimes the Controller and View are
combined, especially in small programs
• Combining the Controller and View is
appropriate if they are very interdependent
• The Model should still be independent
• Never mix Model code with GUI code!
11
Separation of concerns
• As always, you want code independence
• The Model should not be contaminated with
control code or display code
• The View should represent the Model as it really
is, not some remembered status
• The Controller should talk to the Model and View,
not manipulate them
• The Controller can set variables that the Model
and View can read
12
Model View Controller in Grails
Model
Domain objects – map to database tables.
Constraints - validate fields and order the view.
Dynamic - change domain - changes database.
Dynamic Finders - not static - automatically generated from
finder method name - v.cool.
View
Template to display domain objects.
Can use gsp, jsp or html.
Tag libraries - easy to use - can change dynamically.
Controller
Decides what to do when a view submits and action to the
server.
“Flash” feature - for messages in the view.
13
Advantages
Separation between the data layer and the interface is the key:
• The view is easily replaced or expanded.
• Model data changes are reflected in all interfaces because all
views are Observers.
• Better scalability since UI and application logic are separated.
• Distribution over a network is greatly simplified.
14
Advantages
• Modularity
▫ decoupling components
▫ allows each component to be versioned independently
▫ worked on by individuals on team (UI person, DB person, etc)
• Flexibility
▫ multiple Views for one Model (web frontend, desktop frontend,
mobile frontend, etc)
▫ replace one component (replace data storage from flat file to
database)
• Maintainability
▫ only change one component where bug exists, less risk in late
changes
• Testability
▫ each component communicates through contract so each
component can be unit-tested independently
15
Example Scenarios
• Spreadsheet application (classic)
▫ same data (model) spreadsheet can have multiple charts (views)
▫ updating spreadsheet should result in updated charts
▫ example of multiple views, single controller, single model
• Scaling an application
▫ view is desktop or web, model is a flat-file database
▫ updating the database to clustered set of SQL servers
▫ only model needs to take changes for architecture, controller
connects to new model and doesn’t know that the model is now
backed by several DBs instead of one file
• Multiple user interfaces to application
▫ web interface, mobile phone interface, point-of-sale interface,
desktop interface
▫ multiple views, multiple controllers, single model
16
Modern Implementations
• GUI Frameworks for desktop applications
▫
▫
▫
▫
▫
▫
Application Kit – part of Cocoa for OS X desktop apps
GTK+ - part of GTK libraries, used in lots of apps
Microsoft Foundation Classes (MFC) – Document/View Architecture
Java Swing
Windows Presentation Framework (WPF)
TK Toolkit – part of Tcl/Tk
▫
▫
▫
▫
▫
▫
▫
▫
▫
▫
ASP .NET MVC Framework (.NET)
ProMesh.NET (.NET)
Grails (Java)
Struts (Java)
Spring (Java)
PureMVC (JavaScript)
Ruby on Rails (Ruby)
Zend Framework (PHP)
Django (Python)
Pylons (Python)
• Implementations of MVC in web-based frameworks