Web Technologies - kti.tugraz.atkti.tugraz.at/staff/vsabol/courses/wt/wt_slides_mvc.pdf · Need a module system preventing the UI from "seeing" DM functionality ( nally available!)

Web TechnologiesVU (706.704)

Vedran Sabol

ISDS, TU Graz

Dec 03, 2018

Vedran Sabol (ISDS, TU Graz) Web Technologies Dec 03, 2018 1 / 60

Outline

1 Separation of Concerns Design Principle

2 Model-View-Controller Design Pattern

3 Model-View-Presenter

4 Presentation-Abstraction-Control

5 MVC on the Server Side

Vedran Sabol (ISDS, TU Graz) Web Technologies Dec 03, 2018 2 / 60

Architectural PatternsWeb Technologies (706.704)

Vedran Sabol

ISDS, TU Graz

Dec 03, 2018

Vedran Sabol (ISDS, TU Graz) Architectural Patterns Dec 03, 2018 3 / 60

Separation of Concerns Design Principle

Separation of Concerns

Core design principle of all software engineering

Easily supported by object-oriented software development

Definition by Edsger Dijkstra (1974 essay: On the role of scientificthought)

We know that a program must be correct and we can study it from thatviewpoint only; we also know that is should be efficient and we can studyits efficiency on another day [...] But nothing is gained - on the contrary -by tackling these various aspects simultaneously. It is what I sometimeshave called ”the separation of concerns” [...][...]even if not perfectly possible, it is yet the only available technique foreffective ordering of one’s thoughts (focusing of attention)




You want to isolate different aspects of a software application fromeach other

At a single moment you work only on a single aspect (e.g., notdistracted with other aspects)You can work on each aspect in detailsYou can be consistent within each aspectBasis for the team work (e.g., different teams work on different aspects)




Object-Oriented principles easily support SOC

Modularity and encapsulation (classes and objects) isolate aspectsClearly defined interfaces: work on different aspects in isolation

Aspect-Oriented programming: separation of cross-cutting concerns

Concerns affecting most other concerns in a modular software system(e.g. logging, security)Cannot be cleanly addressed by OOP




Architectural and design patterns are also used to achieve SOC

Software layers should have cleanly separated responsibilities

Presentation layer, business logic layer, data access layer (e.g. aWeb-based information system)

Modules separate software in blocks of functionality with no overlap

e.g. Authentication module, workflow engine, messaging subsystem etc.



Benefits of SOC

Reduced complexity (clear interfaces, minimized overlap, etc.)

Simplified integration of aspects and components

Possibility of their reuse or exchange

Easier adaptibility, customization

Improved comprehension of the application domain (immersing intothe domain)



User-oriented database applications - SOC




The interface between UI and Data Management is crucial!

It is where the SOC is violated most

Why is this so?

Example: database contains info about the registered students

Info includes: name, matrikel number, study field




In the process logic you have a Student class

Student class has getter and setter methodsgetName(), getStudyField(), etc.

The UI script (e.g., a PHP script) retrieves a list of Student objects(from process logic)

iterate through the listuse the getters to read informationwrite info in a HTML table




Customer tells that there is another external student database

Contains contact info: addresses, e-mails, etc.

Requirement: include students’ e-mail addresses in the list

(Lazy) developer wants to accomplish this fast

In the UI script: get the matrikel number of each studentConnect to the external database and retrieve the needed info




Problem: mixing UI and data management

Consequences of such ”architecture” can be tremendous

For each change (data access) different UI scripts must be updated

Maintainance nightmare if applied throughout a large application




Proper way of implementing such changes

Student class extension: get/setEMail() methods

Data Management module:

connect to the external databasepopulate student objects with setEMail()

New info available everywhere (UI scripts)

Data access code modifications only at a single place




SOC supported by OO languages, but not enforced

Developers need to take care about this (design)!

Scripting languages are even more vulnerable

You do not need compiling, it is extremely fast to make such changes!Inviting to a bad programming style

But, Java is vulnerable too - you need to take care!

Need a module system preventing the UI from ”seeing” DMfunctionality (finally available!)




One way to improve the situation: a layered architecture

The UI communicates only with the PL module

Again, hard to enforce this

You can only hope that developers will follow the principle!





Model-View-Controller Design Pattern


Model-View-Controller: a particular design pattern that supports SOC

Invented in the early days of GUIs

Roots at Xerox Parc in the 70’s

Still in widest application (Java, .NET, JS frameworks)

MVC also followed by many new frameworks (e.g. angular.js)




Principles

Decouples the graphical interface from the application data and logic

UI is further separated into

data presentationuser input handling logic



Model-View-Controller

Compatible with principles of OOP

state encapsulation, message passing between objects...

The first appereance in Smalltalk-80

One of the first OO languagesPure OO language, i.e., everything is an object

MVC invented by Trygve Reenskaug:http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html


http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html






Controller

”Brain” of the UI (e.g. implements the workflows and the logic withinthe UI)

Handles user input (e.g., mouse clicks, keyboard,...)

Updates the model

Instructs the view to redraw itself




View

Presents the model in a specific way

Manages the display and rendering of information to the user

Note: different views for the same model are possible

Very important: not only desktop GUIs, also inmobile Apps, Webapplications, etc. (e.g., XHTML, PDF, etc.)




Model: contains the data and application logic on the data

Manages the behavior and data of the application

Responds to:

Requests for information about its state/dataInstructions to change state/modify data




Model easily accomplished with an OO programming model

Objects encapsulate the data

Objects implement behaviour (as methods)

Interaction between different objects (i.e., invoking methods) supportsrealisation of complex application logic




Where does the data come from?

If in memory - everything is covered

If externally persisted: in the local file system, RDBMS...

We need a special Data Management module (layer)

Handles persistent data storage (e.g. relational DBMS)

Moves data between memory and storage (e.g. O/R mapping)






MVC - Observer Pattern

A special case of the MVC uses Observer design pattern




When the model changes it notifies the views about the change

A list of all observers is maintained

Views redraw as the result of the notification

Until Ajax not applicable in a Web application

Before Ajax: page-oriented applicationsUser request needed to update each particular view




With Ajax it is possible (Asynchronous request)

On user intraction an Ajax request is performedObservers notified when response is receivedWeb UI remains responsive in the meantimeIt improves the responsiveness of a Web app tremendously

HTML5 WebSockets also provide observer pattern support

Server initiated events/messages




Purpose of the controller is not to separate the model from the view

but to handle user events

To achieve the separation another design pattern is needed

Typically acheived by means of the Observer pattern




Behaviour Diagram


Model-View-Presenter

MVC Variations and Derivatives

A number of patterns derived from MVC

Model-View-Presenter: a further development of MVC

Developed by Apple (1996, project Taligent)

Presentation-Abstraction-Control: a ”hierarchical” version




Separates the concerns of data, data specification, data manipulation,presentation, user interaction, and application coordination




Model: refers to application data and business functionality (logic)

Selections: components specifying what portion of the data withinthe Model is to be operated upon

e.g. define rows, columns, or individual elements meeting some criteria

Commands: components defining operations performed on the data

e.g. deleting, printing, or saving data within the Model




The View is the visual representation of the Model

comprises screens and widgets used within an applicationroutes user input to the presenter and interactorsa lightweight, thin layercan be replaced by different implementations (Web, RIA, desktop,App...)

Interactors: components addressing how user events are mapped ontooperations performed on the Model




Presenter: orchestrates overall interaction of the other components

Replaces the controller taking over the UI logicActs as an intermediary to maximise decouplingDirects the workflow within the applicationHandles creation of Selections, Commands, Views, and InteractorsTypically one per view, but may manage multiple logically related Views




Two variants

Passive View: ”dumb” View separated from the Model

Model events are handled by the PresenterPresenter handles the state and sets View properties (setters)

Supervising Presenter

View connected to the Model (e.g. via data binding mechanisms)Presenter/Interactors still contains logic for handling user events




Model-View-Presenter is how a complex GUI application is built today

Selections and commands are separate components

In a typical system they are defined through interfaces - such as DAOinterfaces and O/R mappers

Data Access Objects (DAO) and Object-Relational mappers provide anabstract interface to a persistant databaseProvide strict separation between bussiness logic and persistance


Presentation-Abstraction-Control


Presentation-Abstraction-Control (PAC): hierarchical MVC variation

Hierarchy of sub-systems where each sub-system follows PAC

Separates concerns of an application into a hierarchy of cooperatingcomponents

Each component depends on a zero or more sub-systemsLinks between sub-systems model associations within an application




Pattern for constructing UIs at different abstraction levels

Application is decomposed into a hierarchy of sub-systems eachpresenting a finer-grained view of an aspect of an application

Example: hierarchically organised administration tools

Advantage: at any level the system is defined using the samearchitectural model







Consist of PAC-triads (Presentation, Abstraction, Control)

Presentation: visual representation of a particular abstraction

Abstraction: the data and business domain functionality (i.e. themodel)

Control: maintains consistency between abstractions and theirpresentation

Also: communicates with other Controls within the system


MVC on the Server Side

Struts MVC

Example using a high-level view of the Struts framework

open-source, Java-based Web application framework



MVC on the server side

The server (a Servlet) receives HTTP requests

Requests include parameters submitted by the userServer produces the response based on the parameters

Server dispatches the request to handlers - called Actions

Actions implement the logic

Registry maintains mappings of parameters onto actions

Server, registry, dispatcher and actions are the Controller



MVC on the server side

The Model is accessed from the actions

Data and behaviour encapsulated within objectsForm beans: data entered by users in HTML formsSession beans: session information that persists between two HTTPrequests by the same userResults beans: information needed to generate the HTML page

Each action is associated with a View

When the action finishes the Controller invokes the View (JSP)The registry also includes associations between actions and viewsThe View accesses the Model, retrieves the data and presents it(HTML)



Ruby on Rails

Ruby is a pure object-oriented programming language

Everything is an object (e.g. the number 1 is an instance of classFixnum)http://www.ruby-lang.org/en/

Interpreted scripting language

Dynamically, weakly typed

Single inheritance, but can be extended with so-called modules(similar to Java interfaces)

Rich text processing functionality (similar to Perl)


http://www.ruby-lang.org/en/


Ruby on Rails

Rails is open source Web application framework

http://www.rubyonrails.org/

Focus on simplicity and productivity

Supports development of Web-based, database-backed application

Follows MVC architecture and design pattern


http://www.rubyonrails.org/


Ruby on Rails

Three main guiding principles

Model-driven development

You start with a data model and add the functionality, controllers,views on top of it

Convention over configuration

Set of naming conventions (similar to JavaBeans but more in depth)

Less software, i.e., less code

Generating default code that you can adjust to fit your needs



Ruby on Rails

Based on an ActiveRecord ORM framework

Similar to HibernateUses a naming convention to provide the default mappingYou can adjust the default mapping if you need to

ActiveRecord naming convention for classes and tables

Name classes as English singularStart the name with an upper case, all other letters are lower case(Student)Name tables as English plural, all lower case (students)



Ruby on Rails

Student class

class Student < ActiveRecord::Base

end

Student table

create table students (

id int not null auto_increment,

name varchar(80),

study_field varchar(10),

primary key(id)

);



Ruby on Rails

Names of the table columns and instance variables

Map 1-to-1, i.e., student.name maps to name column in studentsPrimary key must be named id in the table

Immediatelly you can use all methods from ActiveRecord

@students = Student.find_all

@students = Student.exists

@student = Student.new



Ruby on Rails

To map associations a simple domain language-like set of macros isused, for example

belongs tohas onehas many

see ActiveRecord::Associations::ClassMethods

Connects classes through foreign keys via an associative table(many-to-many relation)

class Student < ActiveRecord::Base

has_one : catalogue

has_and_belongs_to_many : courses

end



Ruby on Rails

Controllers are modules that handle user requests

Convention on mapping of URLs onto methods in controllers

Much easier than Struts configuration



Ruby on Rails

URL = /controller class name/controller method name

For example, http://myhost/test/index

Another example: http://myhost/test/hello

class TestController < ApplicationController

def index

render_text "Wow, that was easy"

end

def hello

render_text "Hello World"

end

end


http://myhost/test/index

http://myhost/test/hello


Ruby on Rails

Whenever you have a model class (e.g. Student) you can use aso-called CRUD (Create, Read, Update, Delete) scaffold

Scaffolding: specify usage of the database, code generated fromtemplates by the framework

create, read, update, delete methodsThese methods are provided by the ActiveRecord

class StudentController < ApplicationController

scaffold :student

end



Ruby on Rails

This single line embeds all of the CRUD methods into controller

Consequently, they are immediatelly visible through URLs

Read: http://my_host/student/show/1

Update: http://my_host/student/edit/1

List: http://my_host/student/list

Note how meaningful and consistent URLs are (discussed this in oneof previous lectures)


http://my_host/student/show/1

http://my_host/student/edit/1

http://my_host/student/list


Ruby on Rails

By scaffolding you also get default views

However, you can adjust them

For a particular controller method, e.g., show() you need to createshow.rhtml

Another naming convention



Ruby on Rails: Advanced Features

Defining layouts (headers, footers, ...)

Modules for standard functionality, e.g., authentication

Caching

Validation and callbacks

Transactions

Testing



Further Readings

Rails Documentation http://rubyonrails.org/documentation/

Rolling with Ruby on Railshttp://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

Rolling with Ruby on Rails, Part 2http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html

Really Getting Started in Rails http://www.slash7.com/articles/2005/01/24/really-getting-started-in-rails


http://rubyonrails.org/documentation/

http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html

http://www.slash7.com/articles/2005/01/24/really-getting-started-in-rails

http://www.slash7.com/articles/2005/01/24/really-getting-started-in-rails

Documents

Web Technologies - kti.tugraz.atkti.tugraz.at/staff/vsabol/courses/wt/wt_slides_mvc.pdf · Need a module system preventing the UI from "seeing" DM functionality ( nally available!)