Web Technologies VU ( ) Vedran Sabol. Nov 13, ISDS, TU Graz. Vedran Sabol (ISDS, TU Graz) Web Technologies Nov 13, / 60

Transcription

1 Web Technologies VU ( ) Vedran Sabol ISDS, TU Graz Nov 13, 2017 Vedran Sabol (ISDS, TU Graz) Web Technologies Nov 13, / 60

2 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 Nov 13, / 60

3 Architectural Patterns and Web frameworks Web Technologies ( ) Vedran Sabol ISDS, TU Graz Nov 13, 2017 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

4 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 scientific thought) We know that a program must be correct and we can study it from that viewpoint only; we also know that is should be efficient and we can study its efficiency on another day [...] But nothing is gained - on the contrary - by tackling these various aspects simultaneously. It is what I sometimes have called the separation of concerns [...] [...]even if not perfectly possible, it is yet the only available technique for effective ordering of one s thoughts (focusing of attention) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

5 Separation of Concerns Design Principle Separation of Concerns You want to isolate different aspects of a software application from each other At a single moment you work only on a single aspect (e.g., not distracted with other aspects) You can work on each aspect in details You can be consistent within each aspect Basis for the team work (e.g., different teams work on different aspects) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

6 Separation of Concerns Design Principle Separation of Concerns Object-Oriented principles easily support SOC Modularity and encapsulation (classes and objects) isolate aspects Clearly 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

7 Separation of Concerns Design Principle Separation of Concerns 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. a Web-based information system) Modules separate software in blocks of functionality with no overlap e.g. Authentication module, workflow engine, messaging subsystem etc. Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

8 Separation of Concerns Design Principle 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 into the domain) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

9 Separation of Concerns Design Principle User-oriented database applications - SOC Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

10 Separation of Concerns Design Principle 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

11 Separation of Concerns Design Principle User-oriented database applications - SOC In the process logic you have a Student class Student class has getter and setter methods getname(), getstudyfield(), etc. The UI script (e.g., a PHP script) retrieves a list of Student objects (from process logic) iterate through the list use the getters to read information write info in a HTML table Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

12 Separation of Concerns Design Principle User-oriented database applications - SOC Customer tells that there is another external student database Contains contact info: addresses, s, etc. Requirement: include students addresses in the list (Lazy) developer wants to accomplish this fast In the UI script: get the matrikel number of each student Connect to the external database and retrieve the needed info Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

13 Separation of Concerns Design Principle User-oriented database applications - SOC 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

14 Separation of Concerns Design Principle User-oriented database applications - SOC Proper way of implementing such changes Student class extension: get/set () methods Data Management module: connect to the external database populate student objects with set () New info available everywhere (UI scripts) Data access code modifications only at a single place Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

15 Separation of Concerns Design Principle User-oriented database applications - SOC 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 DM functionality (finally available!) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

16 Separation of Concerns Design Principle User-oriented database applications - SOC 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! Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

17 Separation of Concerns Design Principle User-oriented database applications - SOC Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

18 Model-View-Controller Design Pattern 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) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

19 Model-View-Controller Design Pattern Model-View-Controller Design Pattern Principles Decouples the graphical interface from the application data and logic UI is further separated into data presentation user input handling logic Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

20 Model-View-Controller Design Pattern 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 languages Pure OO language, i.e., everything is an object MVC invented by Trygve Reenskaug: Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

21 Model-View-Controller Design Pattern Model-View-Controller Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

22 Model-View-Controller Design Pattern Model-View-Controller Controller Brain of the UI (e.g. implements the workflows and the logic within the UI) Handles user input (e.g., mouse clicks, keyboard,...) Updates the model Instructs the view to redraw itself Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

23 Model-View-Controller Design Pattern Model-View-Controller 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 in Web applications etc. (e.g., XHTML, PDF, etc.) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

24 Model-View-Controller Design Pattern Model-View-Controller 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/data Instructions to change state/modify data Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

25 Model-View-Controller Design Pattern Model-View-Controller 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) supports realisation of complex application logic Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

26 Model-View-Controller Design Pattern Model-View-Controller 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) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

27 Model-View-Controller Design Pattern Model-View-Controller Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

28 Model-View-Controller Design Pattern MVC - Observer Pattern A special case of the MVC uses Observer design pattern Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

29 Model-View-Controller Design Pattern MVC - Observer 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 applications User request needed to update each particular view Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

30 Model-View-Controller Design Pattern MVC - Observer Pattern With Ajax it is possible (Asynchronous request) On user intraction an Ajax request is performed Observers notified when response is received Web UI remains responsive in the meantime It improves the responsiveness of a Web app tremendously HTML5 WebSockets also provide observer pattern support Server initiated events/messages Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

31 Model-View-Controller Design Pattern MVC - Observer Pattern 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

32 Model-View-Controller Design Pattern Model-View-Controller Behaviour Diagram Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

33 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

34 Model-View-Presenter Model-View-Presenter Separates the concerns of data, data specification, data manipulation, presentation, user interaction, and application coordination Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

35 Model-View-Presenter Model-View-Presenter Model: refers to application data and business functionality (logic) Selections: components specifying what portion of the data within the 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

36 Model-View-Presenter Model-View-Presenter The View is the visual representation of the Model comprises screens and widgets used within an application routes user input to the presenter and interactors a lightweight, thin layer can be replaced by different implementations (Web, RIA, desktop, App...) Interactors: components addressing how user events are mapped onto operations performed on the Model Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

37 Model-View-Presenter Model-View-Presenter Presenter: orchestrates overall interaction of the other components Replaces the controller taking over the UI logic Acts as an intermediary to maximise decoupling Directs the workflow within the application Handles creation of Selections, Commands, Views, and Interactors Typically one per view, but may manage multiple logically related Views Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

38 Model-View-Presenter Model-View-Presenter Two variants Passive View: dumb View separated from the Model Model events are handled by the Presenter Presenter 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

39 Model-View-Presenter Model-View-Presenter 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 DAO interfaces and O/R mappers Data Access Objects (DAO) and Object-Relational mappers provide an abstract interface to a persistant database Provide strict separation between bussiness logic and persistance Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

40 Presentation-Abstraction-Control 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 cooperating components Each component depends on a zero or more sub-systems Links between sub-systems model associations within an application Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

41 Presentation-Abstraction-Control Presentation-Abstraction-Control Pattern for constructing UIs at different abstraction levels Application is decomposed into a hierarchy of sub-systems each presenting 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 same architectural model Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

42 Presentation-Abstraction-Control Presentation-Abstraction-Control Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

43 Presentation-Abstraction-Control Presentation-Abstraction-Control Consist of PAC-triads (Presentation, Abstraction, Control) Presentation: visual representation of a particular abstraction Abstraction: the data and business domain functionality (i.e. the model) Control: maintains consistency between abstractions and their presentation Also: communicates with other Controls within the system Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

44 MVC on the Server Side Struts MVC Example using a high-level view of the Struts framework open-source, Java-based Web application framework Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

45 MVC on the Server Side MVC on the server side The server (a Servlet) receives HTTP requests Requests include parameters submitted by the user Server 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

46 MVC on the Server Side MVC on the server side The Model is accessed from the actions Data and behaviour encapsulated within objects Form beans: data entered by users in HTML forms Session beans: session information that persists between two HTTP requests by the same user Results 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 views The View accesses the Model, retrieves the data and presents it (HTML) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

47 MVC on the Server Side Ruby on Rails Ruby is a pure object-oriented programming language Everything is an object (e.g. the number 1 is an instance of class Fixnum) 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) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

48 MVC on the Server Side Ruby on Rails Rails is open source Web application framework Focus on simplicity and productivity Supports development of Web-based, database-backed application Follows MVC architecture and design pattern Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

49 MVC on the Server Side 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

50 MVC on the Server Side Ruby on Rails Based on an ActiveRecord ORM framework Similar to Hibernate Uses a naming convention to provide the default mapping You can adjust the default mapping if you need to ActiveRecord naming convention for classes and tables Name classes as English singular Start the name with an upper case, all other letters are lower case (Student) Name tables as English plural, all lower case (students) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

51 MVC on the Server Side 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) ); Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

52 MVC on the Server Side Ruby on Rails Names of the table columns and instance variables Map 1-to-1, i.e., student.name maps to name column in students Primary key must be named id in the table Immediatelly you can use all methods from = = = Student.new Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

53 MVC on the Server Side Ruby on Rails To map associations a simple domain language-like set of macros is used, for example belongs to has one has 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 Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

54 MVC on the Server Side Ruby on Rails Controllers are modules that handle user requests Convention on mapping of URLs onto methods in controllers Much easier than Struts configuration Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

55 MVC on the Server Side Ruby on Rails URL = /controller class name/controller method name For example, Another example: class TestController < ApplicationController def index render_text "Wow, that was easy" end def hello render_text "Hello World" end end Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

56 MVC on the Server Side Ruby on Rails Whenever you have a model class (e.g. Student) you can use a so-called CRUD (Create, Read, Update, Delete) scaffold Scaffolding: specify usage of the database, code generated from templates by the framework create, read, update, delete methods These methods are provided by the ActiveRecord class StudentController < ApplicationController scaffold :student end Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

57 MVC on the Server Side Ruby on Rails This single line embeds all of the CRUD methods into controller Consequently, they are immediatelly visible through URLs Read: Update: List: Note how meaningful and consistent URLs are (discussed this in one of previous lectures) Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

58 MVC on the Server Side 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 create show.rhtml Another naming convention Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

59 MVC on the Server Side Ruby on Rails: Advanced Features Defining layouts (headers, footers,...) Modules for standard functionality, e.g., authentication Caching Validation and callbacks Transactions Testing Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60

60 MVC on the Server Side Further Readings Rails Documentation Rolling with Ruby on Rails Rolling with Ruby on Rails, Part 2 Really Getting Started in Rails /01/24/really-getting-started-in-rails Vedran Sabol (ISDS, TU Graz) Architectural Patterns and Web frameworks Nov 13, / 60