Study of Patterns in an Agile Web Development Environment

Radek Štěpán


MSc in Advanced Computer Systems:
Internet Systems 2010

Acknowledgments

Abstract

Biases Declaration

Part I. Introduction

1 Project Background

1. Identify the concerns a web application architecture has to handle and the different forces put on it.
2. Identify approaches used to describe web application architectures.
3. Evaluate critically the patterns, models and approaches relevant to a development of a web system that adhere to sound software engineering principles in the web domain.
4. Explore the merit of the different approaches identified in 3. and their synergic collaboration and effect.
5. Formulate architecture recommendations for industry web developers and web engineering academics alike.
   

1.1 Problem

1.2 Thesis Guide

Part Part II↓, Web Application Architecture

Part Part III↓, Patterns, Methods & Architectures

Part Part IV↓, From Requirements to Code

Part Part V↓, Project Conclusions

Part II. Web Application Architecture

2 Web Applications Background

2.1 Classification & Definition

1. Web hypermedia applications - these applications are used to publish information on the web with users navigating through nodes, links and anchors linking to the content.
2. Web software applications - are conventional applications that use web for their execution.
3. Web applications - are applications combining the previous two concepts.

1. Thin web clients - where all the processing happens on the server-side.
2. Thick web client - the client requesting data processes them through enhancements such as JavaScript.
3. Web delivery - are fully distributed systems where client and server maintain a state through protocols such as IIOP, DCOM and RMI.

1. Client front-end - displaying content served by the server and making requests to it.
2. Middle layer - this is the domain of content processing and generation through application server technologies, platforms.
3. Database layer - a database server managing data.

Online client-server applications executed on and served by an HTTP(S) web server technology accessed through URL schemes.

1. Applications that run primarily on a client-side technology such as JavaScript, storing client data in cookies [C]  [C] An example of which could be the various “to-do list” applications. or in an HTML5 JavaScript database class (see Section A.1 ↓).
2. Applications that use RFC3875 Common Gateway Interface (CGI) programs [133] launched by web servers such as Apache, IIS, nginx or lighttpd to execute technologies such as PHP, ASP, .NET, Python, Ruby on the server-side.
3. Everything in between, using various means of storage and either browser or server processing [D]  [D] A special case would be offline web applications that run from local source files only. We are interested in applications that require a web server for their execution..

2.2 Web Application Environment & Specifics

Figure 2.1 The tiered nature of web applications.

2.2.1 Request & Response Cycle

1. Handle HTTP request methods, most commonly GET and POST, and their processing. Examples: form input, file uploads, different user agents, technologies used such as Ajax, different server configurations.
2. Handle different HTTP server responses. Examples: status codes, content types (HTML, XML, JSON), cookies, caching, character set encoding.
3. The client should ideally remember its state as all rendered information is lost during a standard, synchronous, request.

2.2.2 JavaScript and Ajax

2.3 Discussion of Web Application Background

3 Layers

Figure 3.1 4-Layers Pattern.

Persistence Layer

Business or Functionality Layer

Control Layer

Presentation Layer

3.1 Navigation Layer

3.1.1 National Gallery of Art

Figure 3.2 National Gallery of Art demo site.

Soprano Framework

Figure 3.3 Soprano framework execution flow diagram.

<?php
include(’../lib/soprano.php’);
​
class Application extends Soprano {
​
    // painting listing
    public function getIndex() {
        $this->template->paintings = $this->dbSelect("SELECT * FROM paintings");
        $this->template->render(’index’);
    }
​
   // detail view of the painting
    public function getDetail($painting) {
        // ideally we would filter the query in the router and nevertheless the DB layer would throw exceptions based on failed validations
        if ($result = $this->dbSelect("SELECT * FROM paintings WHERE id=$painting")) {
            $this->template->painting = $result;
            $this->template->paintings = $this->dbSelect("SELECT * FROM paintings");
            $this->template->render(’detail’);
        } else {
            $this->template->render(’no-detail’);
        }
    }
​
}
​
$app = new Application();
​
$app->get(’/’, ’getIndex’);
$app->get(’/detail/:painting’, ’getDetail’);
​
$app->run();

1. First the request from a client is received by the framework (through an irrelevant step of bootstrapping).
2. The framework instantiates the class that corresponds to our application, it has two methods and accepts two routes from the client. Let us say that a user’s request will ask for  ⁄ detail ⁄ 6. This route corresponds to a pattern that we match for,  ⁄ detail ⁄ :painting and a corresponding method getDetail(), accepting one attribute, painting that is extracted from the request. In our case, it is the string 6 [K]  [K] At this point we have to clarify that PHP is dynamically typed..
3. The method getDetail() is thus called. This method makes a search for the painting with an id of 6 from a database. If found, it will respond to the client with the appropriate painting detail, and if not, it displays an error message built into a template.

Business Concern

Figure 3.5 NGA database table maintaining paintings.

3.1.1.1 Resources ≠ Pages

Figure 3.6 MVC-Webflow navigation design, reproduced from [38].

3.1.1.2 Semantic Web

3.2 State Layer

3.2.1 State on the Client

1. HTML hidden fields. This is the technique where a form is created with hidden fields that contain state information. The disadvantage is that a lot of information is saved on the client and thus this negatively affects the performance. An approach used in ASP .NET 2.0 is to encrypt this information on the client [N]  [N] With a directive <%@ Page EnableViewStateMAC="true" %>. and then validate the checksum when the data are unserialized [O]  [O] Serialization is a process of translating objects into a series of bits or characters with a prescribed encoding so they can be transferred between systems. by the application, this means that invalid/modified data are discarded [104].
2. Cookies. Cookies are similar to hidden fields but are easier to implement, however they might be blocked by the browser and are only of limited size. They are valid though, as [104] note, for personalization as cookies can remain on the client for longer.

URL Query

3.2.2 State on the Server

1. Session State. Used for e.g. shopping baskets and is secure especially if SSL is being used. This represents saving data into a session that is accessed through the ID of the client.
2. Application State. An approach specific to ASP .NET where data are saved for all clients in one repository that represents the application. Such data are “saved” until the application or the server are restarted. As clients can overwrite each others saves to the data store, two functions, Lock() and Unlock(), are employed to explicitly allow only one client to access the application state collection at a time. Unfortunately this means the rest of the clients have to wait for the lock to be released [104].
3. Profiles. An ASP .NET specific approach with data being serialized into a database. Therefore all other applications can access the data as well but this approach results in an overhead during the saving and retrieval.
4. Caching. An extension of profiles where data in the database can be optimized to perform a cleanup.

Figure 3.7 ASP .NET session state architecture, reproduced from [104].

3.2.2.1 ModelState

<?php
​
class Hangman {
​
    private
        $word,
        $guess,
        $left,
        $round;
​
    public function startNewGame() {
        // parse a random word
        $words = file_get_contents(APP_DIR . "/models/words.txt");
        $words = explode("\n", $words);
        $this->word = strtoupper(trim($words[rand(0, count($words))]));
​
        // initialize our word to guess
        $this->guess = array();
        foreach (str_split($this->word) as $letter) {
            $this->guess[] = array($letter => ’_’);
        }
        $this->left = $this->getLength();
        $this->round = 1;
    }
​
    /**
     * Make a guess.
     * @param  $letter
     * @return bool true if we have won
     */
    public function guess($letter) {
        foreach ($this->guess as &$g) {
            // if we have a match and are not guessing the guessed again...
            if (key($g) == $letter && current($g) == ’_’) {
                $g = array($letter => $letter);
                $this->left--;
            }
        }
        $this->round++;
        return ($this->left <= 0);
    }
​
    public function getLength() {
        return strlen($this->word);
    }
​
    public function getGuessed() {
        return $this->guess;
    }
​
    public function getRound() {
        return $this->round;
    }
​
}

<?php
​
class HangmanState extends State {
​
    public function getObjectName() {
        return ’Hangman’;
    }
​
    public function initialize() {
        $this->startNewGame();
    }
​
}

<?php
​
final class Factory {
​
    /**
     * Build a model object or its stateful adapter.
     * @static
     * @param  $model
     * @param  $state
     * @return Object
     */
    public static function build($model, $state=null) {
        $stateFile = APP_DIR . ’/states/’ . ucfirst($model) . ’State.php’;
​
        // is model stateful?
        if (is_readable($stateFile)) {
            include_once $stateFile;
            // database access
            include_once "db.php";
            // name convention
            $model .= ’State’;
            // build it
            return new $model($state);
        } else {
            // return a new vanilla model
            if (is_readable($modelFile = APP_DIR . "/models/{$model}model.php")) {
                return new $model();
            } else Application::exception(’model not found!’);
        }
    }
    
}

1. Ask for a Hangman class maintained in a session on the server (serialized or hashed into a string).
2. Hangman class does not exist, but a HangmanState class does, therefore create a new HangmanState class that has Hangman as its inner class. This is an example of a Decorator↓ or Proxy↓ Adapter↓ pattern [67], with HangmanClass “wrapping around” Hangman and directing all method class to it.
3. Once we have processed the request, just before we are responding to the client all classes are destroyed by the server. Therefore we have a hook in a PHP magic [Q]  [Q] Official term, see http://www.php.net/manual/en/language.oop5.magic.php method __destruct() that lets us define what happens to a class we work with just before it is destroyed. The HangmanState class extends State that has __destruct() defined as a method that serializes the inner HangmanClass.
4. Repeat, in the next step though, we are going to unhash a class in a particular state this time.

3.3 Discussion of Layers

4 Concerns

Autonomous view

Figure 4.1 Autonomous view.

4.1 Separation of Concerns

<?php
​
$url = "http://www.specialtip.com/"; # url
$input = @file_get_contents($url) or die(’Could not access file: $url’); # load
​
# regex
mb_internal_encoding("UTF-8"); # set encoding
if (preg_match("/Aktivní .* (tip|tipy)./", $input, $matches)) {
​
    # file
    $fh = fopen("status.txt", ’r’); # open file (read only)
    $d = fread($fh, 200); # read file
    
	if ($d != $matches[0]) { # file is different (new status)
		echo ’<span style="font-family: calibri">new status<br>’;
		$fh = fopen("status.txt", ’w’); # delete original contents
		echo ’file cleared</span><br>’;
	
        fwrite($fh, $matches[0]); # write new status to file
​
        # send emails
        $msg = $matches[0]."\n\n".’http://www.specialtip.com/tipy’;
        $to = array("email@gmail.com", "email@fbi.gov"); # recipients
        foreach ($to as $key => $recipient) {
            mail($recipient, "Nový tip od SpecialTip.com ".date("D dS M, Y h:i a"), $msg,
                "From: admin@tipsfortune.com"); # send mail
        }
        echo ’<span style="font-family: calibri;background:#cefcd2">notifications sent</span>’;
    }
    else echo ’<span style="font-family: calibri;background:#f8f9cc">no new picks, some are active</span>’;
    fclose($fh); # close file
}
# no new tips (clear the file)
else {
	$fh = fopen("status.txt", ’w’);
	fclose($fh);
	echo ’<span style="font-family: calibri;background:#fed9dd">no active picks</span>’;
}

echo ’<span style="font-family: calibri;background:#cefcd2">notifications sent</span>’;

4.2 Crosscutting Application Concerns

Figure 4.4 Crosscutting concerns in a web application, reproduced from [89].

4.3 Discussion of Concerns

5 Web Application Architecture

5.1 Reuse and Associated Issues

5.1.1 Architecture

1. We need to determine what is the flow and transfer of control between parts of the system and in what hierarchy these parts or components exist.
2. Consider the communication of data between the various components. Are the data shared, perhaps through an intermediary? Or are they globally available?

5.2 Programming Paradigms

5.2.1 Object-oriented Programming

1. The Single Responsibility Principle - “A class should have one, and only one, reason to change [50, 119].”
2. The Open Closed Principle - conveys we should be allowed to extend class behavior, without modifying it [111]. This principle is especially useful in web development as applications have a shorter release cycle and thus are expected to change often [81].
3. The Liskov Substitution Principle - posits that a subclass should behave like the super-class. Let us illustrate that this principle does not apply only to inheritance. We could extrapolate it to mean that if a request is made to the server, the code representing an abstract response to the client should be capable to handle the request in a similar way. For example, it should not matter whether we ask for data in format X or Y or whether we request page A or B.
4. The Interface Segregation Principle - suggests the use of fine-grained client specific interfaces; then the clients using them only know about the methods they are going to use [132].
5. The Dependency Inversion Principle - advises we depend on abstractions and not on concretions.

Aspect-oriented Programming, Subject-oriented Programming

5.3 Inheritance

5.3.1 Object Composition

5.3.2 Multiple Inheritance

5.3.3 Structured Inheritance Relationships (SIRs)

1. Variant relationship - serves to introduce an operation in a super-class with implementation variants in its subclasses. However this relationship can be replaced using a Template Method↓ pattern discussed in Section 5.7.3 ↓.
2. Construction relationship - similar to variant but we are not necessarily looking for code substitutability. Should we then not use object composition if the relationship is not an exact “is-a” instead? Object type can be enforced through interfaces.
3. View relationship - achieves code reuse such as “a view of a target is-a target instance looked at in a particular way [68]”. These could be roles that an abstraction plays during communications with other abstractions. Therefore, as an alternative, the Role Object↓ pattern [27] suggests objects to have separate role objects that are dynamically attached and removed. While, if we want to simply provide a further set of operations for use in certain contexts, we can use the Decorator↓ pattern that allows us to broaden an object’s functionality dynamically [67].
4. Evolution relationship - a useful relationship in which a complex abstraction is built up over time. Alternatives are a Template Method↓ pattern if the core logic stays the same. An ↓Adapter pattern, on the other hand, can be used to convert an interface of one class to be what another class expects. Such would be a case of a new version of a class extending the original one, an evolution.

5.3.4 Traits

5.3.5 Proper use of inheritance

5.4 Patterns

Architectural Patterns

Design Patterns

Idioms

Other Patterns

5.5 Modifiability Tactics

5.6 Algorithms

5.7 Frameworks

1. As semi-complete applications consisting of reusable and extensible sets of components [16]. These domain specific components, patterns [56], form the architecture of the application and leverage the domain knowledge of experienced developers as a consequence [138].
2. As reusable designs built from sets of classes and models of domain-specific object collaborations [141].

1. White-box frameworks - require us to understand the internals to use them effectively while usually taking advantage of inheritance, [86] state.
2. Black-box frameworks - require no deep understanding and behavior is usually extended by object composition [156].

5.7.1 Web engineering approaches

1. WARP [33] - has a schema editor (HDM2000), a content manager (XML) and a publishing editor (XSL). Alternatively this problem could be approached as one of document publishing and versioning resulting in a CMS. For example, SilverStripe CMS with its Sapphire Framework allows us to determine our own schemas and an admin interface is automatically generated for us, all from one application. Django is another representative of an admin building web framework built in Python. We will discuss these further in a section of Naked Objects↓ architecture (Chapter 13 ↓).
2. OOHDM [142, 134] - the reasoning behind the Abstract Data View architecture used is to allow the application to generate data according to the context. Unfortunately, alternative, MV* patterns based approaches, such as Model-View-Presenter↓ (MVP) [W]  [W] We evaluate this pattern in Chapter 10 ↓. are not evaluated by Rossi [ibid.]. Rossi has since moved on to name web design improvements, a catalog of navigational and presentation web application models.
3. Web Actions Framework [87] - the authors are describing an MVC↓ pattern, yet do not mention this fact anywhere in the literature.
4. Atomic Section model [116] - rather than representing a framework per se, ASM constitutes an approach of splitting a page into atomic parts called a component interaction model (CIM) with a fixed application transition graph (ATG) that directs the user through nodes - pages. A finite state machine - state transition graph aids in testing, and such approach has its merit [110], but this solution does not deal with the separation of concerns problem and results in code being mixed throughout HTML tags.

Web Engineering discipline

5.7.2 Architectural patterns-based approaches

• Struts, Grails, JSP - aimed at Java developers
• ASP .NET MVC - based on Microsoft’s ASP .NET
• CakePHP, CodeIgniter, Nette, SilverStripe, Symfony, Zend - PHP offerings
• Django - a Python framework that automatically generates views, the presentation of our application, and leaves us to primarily define the business logic of the application
• Ruby on Rails - a Ruby framework

5.7.3 Discussion

5.8 Middleware

5.9 Discussion of Web Application Architecture

6 Summary of Part II, Web Application Architecture

“Patterns expose knowledge about software construction that has been gained by many experts over many years. All work on patterns should therefore focus on making this precious resource widely available. Every software developer should be able to use patterns effectively when building software systems. When this is achieved, we will be able to celebrate the human intelligence that patterns reflect, both in each individual pattern and in all patterns in their entirety.”

Part III. Patterns, Methods & Architectures

7 Patterns

7.1 Knowledge Vaporization

7.2 Pattern Documentation

7.2.1 Pattern Form

7.3 Discussion of Patterns

8 Model-View-Controller↓

8.1 Problem

“A system may offer multiple user interfaces. Each user interface depicts all or part of some application data. Changes to the data should be automatically and flexibly reflected to all the different user interfaces. It should be also possible to easily modify any one of the user interfaces, without affecting the application logic associated with the data.”

8.2 Solution

1. Model component that encapsulates application data and the logic for manipulating the data. This should happen independently of the user interface(s) used.
2. As has been mentioned, the system has to have a user interface. This part is the concern of a view component.
3. The third component is a controller that is associated with views, encapsulating more or less extensive application logic.

8.2.1 Observer and Event-Listener Patterns

Figure 8.1 Component diagram of a generic Model-View-Controller architecture.

8.3 Desktop MVC

8.3.1 MVC/79

Figure 8.2 MVC/79.

8.3.2 MVC/80

Figure 8.3 Traditional version of MVC as a compound pattern.

Figure 8.4 Sequence diagram in a class Model-View-Controller architecture.

1. A controller is notified of an event triggered by the user on a view component.
2. The model is subsequently updated with the new information contained in the notification. This is an example of a strategy employed on part of the controller.
3. The Observer pattern is employed to notify the view of a model state change.
4. The view updates its state. We see that this is an example where a user has a view of the model and both need to stay synchronized.

8.3.3 Cocoa MVC

Figure 8.5 Cocoa MVC using Mediator and Strategy pattern in the controller.

1. We see that the controller is now the mediating part allowing for more functionality. A Command↓ pattern, in this case, represents a specific method in a controller being invoked as a response to an event in the view. We call the specific method an “action”. As the model is no longer directly connected to the view, we call the controller as performing a restrict communication path tactic a special case of use an intermediary that removes a dependency between a called and calling object.
2. The controller action decides which models need to receive the new information.
3. Finally the controller is notified of a state change to the model and thus updates the views that depend on it.

8.3.4 Model-View-Controller++

Figure 8.6 MVC++.

8.4 Web Model-View-Controller

8.4.1 Push Based / Service to Worker Strategy

Figure 8.7 Service to Worker.

Ruby on Rails

1. All requests are routed through a Front Controller that is a specialisation of an ApplicationController class. It decides which controller and action to launch. For example requesting  ⁄ paintings ⁄ delete ⁄ 5 will instantiate a Paintings controller and call its method delete with a parameter 5.
2. The controller than makes a connection to an appropriate number of models to process the request.
3. Finally, a view associated with that controller action of the same name will be invoked traversing received data as appropriate and sending them back as a response to the user.

8.4.2 Pull Based / Component Based / Dispatcher View Strategy

Figure 8.8 Dispatcher view.

JavaServer Faces

1. Restore view. Based on the HTTP request the view that dispatched the request is identified. The view consists of a tree structure of components that consists of fields and, where appropriate, attached validators to these fields. Some fields also act as event handlers. The structure is built-up based on how the components looked like at the end of the previous request.
2. Apply request values. In this stage, the fields are updated based on new values received from the client. As they know about their previous state, they can notify of their change.
3. Process validation. In this phase, the attached validators are activated. If at least one component fails its validation, we continue to the last step - responding to the user with a view showing where the validation has failed.
4. Update model values. If the validation of components has succeeded, we can continue with this step. We know the data are valid in terms of their attached validators but we still need to contact the model to verify whether they are valid from a “business” perspective. For example a field with a user name might have a validator stating that one has to input at least 5 characters while from a business perspective the user name might have been used in the system already and needs to be unique (thus requiring a call to the persistence layer). Business Helper component is therefore employed to validate the request.
5. Invoke application. We now have validated data in a request, therefore a method associated with the form that invoked the whole request is called on the model component.
6. Render response. The model has finished processing and the result of the request has been received. A transfer of control is given to the view that directs the response to the user.

8.5 Merged Variants

8.5.1 ↓Model-Controller & View-Controller↓

8.5.2 Document-View

8.6 MVC Evaluation

8.6.1 Observer vs Mediator

8.6.2 Architectural Primitives

1. First, [83] identify a Push-Pull primitive in the MVC pattern commenting that the model pushes data to the view and the view can pull data from the model. In the Web MVC variant using the mediating controller, it is the controller that does the pushing and the pulling.
2. Next on the list is a Virtual Callback that involves a called component keeping a reference to the calling object [83]. [83] state that the view and model components may communicate with each other through a callback operation, the Web MVC variant does no such thing. However, as we will discuss later, in some implementations of the MVC pattern on the web, multiple controllers are used in one call, calling each other recursively. However, this is out of the scope of the discussion presented here.
3. Forward-Request abstraction represents a situation where an internal “system” is decoupled from the external “objects” [83]. We would state that the Front Controller or router commonly used in Web MVC represents an object that translates an external formal request in HTTP onto internal application logic calls.
4. Command abstraction identifies a case where calling an object will invoke a specific method [83]. The definition does not make it clear, whether the Command abstraction is the same as the Command pattern [67]. [83] state that this abstraction is found in MVC. As Controllers are invoked on their actions [E]  [E] Action is a common name for a method in a controller. by an external request, we find the same thing in Web MVC too.
5. Asynchronous Message abstraction or asynchronous communication is to be found in the Client-Server pattern scenario [83]. As the Web MVC, especially its implementation in Ruby on Rails [135] often relies on Server-Side Generation [105] of asynchronous requests [F]  [F] An example is generating JavaScript code for the client view., we can find this abstraction in Web MVC too.
6. Passive Element is an abstraction where an object cannot invoke any operation [83]. It can be found in MVC [83] and it can be found in Web MVC in a form of an HTML page that contains no links or buttons or in a form of an email. Here, we should point out that although views are often graphical, they do not have to be [51]. As was mentioned earlier, an email class represents a presentation as well. It is a way of presenting data to a user.
7. In a Control abstraction invoking a method on an object may involve a transfer of control and is found both in MVC/80 [83] and Web MVC.

8.6.3 Modifiability Tactics

Increasing Cohesion & Reducing Coupling

Reducing Coupling

Run-time

8.6.4 MVC Consequences and Issues

1. Multiple views of the same model. On a desktop a model is associated with one or more views, while if we use a mediating controller, then one calls multiple models to bind data to multiple views. Thus the mediating controller solution in Cocoa MVC/Web MVC is more flexible.
2. Synchronized views. This point relates to the fact that views work like observers of models a fact that only holds true to the desktop version of MVC. In Web MVC the advantage of having synchronized views does not exist as the user always initiates a request, be it synchronously or behind the scenes - asynchronously. The last option would give the user the “illusion” of being always synchronized with the data, by using a Distributed Events pattern [105], that represents a client constantly checking for model updates. The only exception would be a Comet or “reverse Ajax” technology that is still in its infancy. In the chapter on maintaining state (Chapter 3 ↑) we have discussed that web servers do not maintain state to not become overloaded with numerous requests.
3. Pluggable views and controllers. Be it desktop or Web MVC, one can exchange view, controllers or models. Ideally, one would replace controllers and views behind a model easily in Web MVC, but we often see whole projects being started, re-written from scratch and this is symptomatic of a logic spread throughout models, controllers and sometimes, unfortunately, views too.
4. Exchangeability of “look and feel”. A point made referring to the way a desktop application can change its user interface. In the Web MVC implementation the look & feel is often “set” using a cascading style sheet (CSS) or extensible stylesheet language transformations (XSLT) [105]. A declaration to a CSS file is done in a head of an HTML page and this part of the presentation logic is usually encapsulated in a layout component that is set for a view. Thus the exchangeability holds true. An interesting approach is taken by SproutCore framework that extends the MVC model with Server Interface, Display and Responders components [5]. The Display part specifically empowers the browser and associated JavaScript frameworks to repaint, resize and animate content. With increasing browser optimization and power of JavaScript frameworks a step in a right direction as it highlights code in a presentation layer that is often not described in web applications. What we mean is that a presentation behavior is often dismissed and left out from various flow diagrams and focus rests on the server components.
5. Framework potential. The popularity of the pattern on desktop and on the web attest to that [146]. A Wikipedia entry listing and comparing web application frameworks [G]  [G] http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks, accessed 17^th August 2010. lists 55 out of 67 as using the Model-View-Controller pattern. The pattern is popular perhaps due to its simple three layer split that, in the web domain, does not impose any rules as to where application functionality should find its place and a fact that it has been selected as the pattern for application architecture in [12]. But as no rules and restrictions are imposed, this also means that junior developers can develop a working system now that will be less reusable later. An often repeated example is including too much business logic in controllers where it does not belong.
6. Potential for excessive number of updates. As the views observe a model in MVC/80 this is a problematic fact. In Web MVC with no such behavior a single request is responded with a single reply. A potential for excessive updates happens in Dispatcher View MVC when users asynchronously refresh a content they are viewing as each time the framework has to understand the request, where it is authorized and build all the components required anew (Section 8.4.2 ↑). Therefore, the simpler Service to Worker strategy is preferred.
7. Intimate connection between view and controller. [39] have argued that these two components are closely related and they would unlikely be used without each other. In Web MVC a controller does not have to call a model and does not even have to call a view. We should perhaps note that one can return data to a client without using a view. What we are arguing is that one does not have to reply to a client apart from a standard “200 OK” response. For example, one can increasingly find a Periodic Refresh pattern [105] which represents a recurring asynchronous call, simply to keep a client/browser session alive. In such a case the controller will (has to) be involved. Using a controller without a view in Web MVC or Cocoa MVC is problematic considering the controller acts as a mediator between the view and the model, especially in Web MVC where the processing starts with a controller. A solution, already mentioned, would be to setup the framework/application router to directly call views from a repository skipping controller processing. But such a solution is unlikely to find prevalence as it would minimize the execution time of a framework only a little with network transfer still being the Achilles [79] heel.
8. Close coupling of views and controllers to a model. [39] mentions that both views and controllers make calls to a model so a change to its interface will break the code. In Web MVC it is usually possible to call a model directly [H]  [H] For example in PHP, one can just include a class file and then use it., but the framework designers can discourage such behavior by using a custom templating language in the view that has no concept of calling a function or a class from a template, such is a case of Sapphire Framework of SilverStripe CMS (see Figure 8.9 ↓ for an example of a custom templating language). A different problem is how one binds model data to a view. Such a case will be better illustrated in our future discussion of the ↓Model-View-Presenter (Chapter 10 ↓) and Model Adapter↓ (Chapter 11 ↓) patterns. MVC is not flexible enough to address this concern on its own.
   Figure 8.9 SilverStripe template.

   ...
   <div id="studies" class="span-40 last">
       <% control Page(studies) %>
           <% control Children %>
               <div class="span-19 <% if Odd %>last<% end_if %> study">
                   $CalloutImg
                   <p>$Content.LimitWordCountXML</p>
                   <a class="orange-text" href="$Link">Click here to find out more ></a>
               </div>
               <% if Odd %>
                   <div class="span-2">&nbsp;</div>
               <% end_if %>
           <% end_control %>
       <% end_control %>
   </div>
   ...
   

9. Inevitability of change to view and controller when porting. The beauty of web frameworks is that most of their application code is being written in one language [I]  [I] However a haXe language attempts to become a “universal language” being able to translate into Flash, PHP, C++ and JavaScript.. Therefore, one cannot port from a PHP environment to a .NET environment. At the same time, all browsers “should” handle the HTTP protocol and HTML language the same way. They do not do so and one solves this problem by using a custom CSS code/hacks or JavaScript frameworks on the desktop as introduced in point #4 in this account. All in all, usually a tweak is required to the view code if there is a problem with the application’s presentation in a particular browser.
10. Observer behavior is hard to understand and debug [58] is a point we have mentioned earlier. Luckily the mediating controller in Cocoa MVC/Web MVC approach is more linear and thus easier to understand.
11. [78] would suggest that the MVC approach is not maintainable at all. It cannot be called object-oriented because “there is just too much data flowing around” [ibid.]. This point will be better addressed in a chapter on Naked Objects architecture (Chapter 13 ↓) that will compare Naked Objects with MVC. By the time we will have presented the reader with project conclusions (Part IV ↓), we will actually see that one can create a maintainable system that addresses Holub’s concern.

8.7 Discussion of MVC

9 ↓Data Transfer Object

9.1 Problem

9.2 Solution

9.2.1 Example in Zend Framework

<?php
​
public class IndexController extends Zend_controller_Action {
    ...
    public function indexAction {
        // create a DTO object based on data from a model
        $dto = new customDTO($model->getArticle());
        // create a view
        $view = new Zend_view();
        // assign model data to the view
        $view->assign(’article’, $dto);
        // call the view to render itself
        $view->render(’article.phtml’);
    }
​
}

...
<h1><?php echo $this->article->getTitle(); ?></h1>
<p><?php echo $this->article->getText(100); ?></p>
...

Figure 9.3 Data Transfer Object in Zend.

1. The controller calls the application logic (model) asking for an article.
2. Model responds with an object, perhaps an row from a database table, that represents the article entry.
3. Controller instantiates a new, custom, DTO.
4. DTO is assigned to the view.
5. Controller asks the view to render itself.
6. While traversing the page template, the view calls the DTO for data.
7. The DTO has methods in place that return the article data.

9.3 Discussion of DTO

10 ↓Model-View-Presenter

10.1 Taligent Model-View-Presenter

Data Management

1. What is my data? This is the responsibility of the model component, same as in MVC, that handles the data and the core business logic/functionality.
2. How do I display my data? Handled by a view component that we know from MVC is responsible for the displaying of the data on a screen or “displaying” the data by sending them in an e-mail, for example.
3. How do I specify my data? Selections components handle the task of selecting which parts of the model data we will operate upon in the view. In MVC/80 this task is handled in the model, but in Web MVC is often done in the controller layer - let us remember this fact for later.

Figure 10.1 Taligent asking “How do I manage my data?”, reproduced from [122].

User Interface

1. How do events map onto changes to my data? This is the link that connects the user events such as a mouse click onto the models, in Taligent solved using Interactor components.
2. How do I put it all together? A broad question with a simple answer - use a Presenter↓. This component creates and maintains all the components introduced herein and above, it directs the workflow within the application.

Figure 10.2 Taligent asking “How does the user interact with my data?”, reproduced from [122].

Figure 10.3 Taligent MVP.

1. The view component is where all events are launched. As we are discussing a desktop environment pattern, we do not differentiate between the client and the server view.
2. The focus is put on a Presenter component that observes an Interactor where all events are received. The view and Interactor form a UI layer.
3. The Presenter is a component that decides what commands to invoke on the Data Management layer, the left side of the triangle.
4. The Commands component knows of actions that change data.
5. While the Selections component decides which portion of the data to edit and/or update.
6. The model defines the data themselves.
7. The base of the triangle represents a notification framework between the view and the model. The view gets updated by the model.

10.2 Dolphin Smalltalk Model-View-Presenter

Figure 10.4 Dolphin Smalltalk MVP.

10.3 Generic Model-View-Presenter

10.3.1 Supervising Controller and Passive View patterns

Figure 10.5 Supervising controller.

Figure 10.6 Passive view.

10.4 Web Model-View-Presenter

1. We have already stated that in Dolphin Smalltalk the views delegate requests to the Presenter when model needs to be involved. If we do not count a presentation logic on the client in form of a JavaScript then the views cannot really be “smart” and in Web MVP should contain minimum of application logic [37].
2. The previous point is extended by the fact that the application should be testable, thus moving complex logic from the views into a Presenter (a Supervising Controller) [63].
3. A Presenter directs the workflow within the application [122].
4. From the description of Dolphin Smalltalk MVP the Presenter mediates updates the model on behalf of the view [37].
5. In Taligent MVP it was the Selection components that would select which parts of the model data we will operate upon in the view [122]. In Web MVC this task is often done in the controller layer.

Given there are no formal definitions of Web MVC or Web MVP, the former is closer to the Model-View-Presenter pattern than to the Model-View-Controller pattern that it stems from. To put it simply, a vast amount of “MVC frameworks” on the web are actually MVP.

10.4.1 Nette Model-View-Presenter

1. The model is limited to operations with data and/or a database.
2. The logic contained in views is limited to simple if/else statements.
3. The logic in the Presenter builds up an overall component tree and queries the model.

10.5 Discussion of MVP

...
<tr>
    <th class="align_right" colspan="4">Total cost of products in basket</th>
    <td class="align_right" colspan="2"><span>&pound;
    <?php echo money_format(’%.2n’, round(($this->cartTotal - $this->deliveryCharge) * $this->vat, 2)); ?></span></td>
</tr>
<tr>
    <th class="align_right" colspan="4">Postage and packing</th>
    <td class="align_right" colspan="2"><span>&pound;
    <?php echo money_format(’%.2n’, round($this->deliveryCharge * $this->vat, 2)); ?></span></td>
</tr>
<tr>
    <th class="align_right" colspan="4">ORDER TOTAL</th>
    <td class="align_right" colspan="2"><span>&pound;
    <?php echo money_format(’%.2n’, round($this->cartTotal * $this->vat, 2)); ?></span></td>
</tr>
<tr>
    <th class="align_right" colspan="6"><p>Your purchases have raised <span>&pound;
    <?php echo money_format(’%.2n’, round(($this->cartTotal-$this->deliveryCharge) * $this->vat * $this->commission, 2)); ?>
    </span> for <?php echo $this->school ?></p></th>
</tr>
...

11 ↓Model Adapter

11.1 Problem

11.2 Solution

11.2.1 Dibi DataSource Example

<?php
​
// the presenter
class AnyPresenter extends presenter {
    ...
    public function renderDefault($page) {
        $articles = $this->model->getArticles();
        // extra condition
        $articles->where(’category = %i’, $this->category);
        // bind articles to the template
        $this->template->articles = $articles;
    }
}
​
// the model
class model {
    function getArticles() {
        return dibi::dataSource(’SELECT ... FROM table WHERE ...’);
    }
}
​
// the view
<h1>Article listing</h1>
<?php foreach ($articles->select(array(’url’, ’name’, ’id’))->orderBy(’date’) as $article): ?>
    <h2><?php echo $article->name; ?></h2>
    <p><a href="<?php echo $article->url; ?>"><?php echo $article->id; ?></a></p>
<?php endforeach; ?>

11.3 Discussion of Model Adapter

Figure 11.2 DiBi Model Adapter flow of events in MVP.

1. An HTTP request is received on the Presenter that decides which model to invoke.
2. We request a Model Adapter that represents a collection of items we want to paginate over.
3. The ↓Presenter builds a paginator. A paginator is purely a presentation concern. The model does not care whether the data it provides is displayed on 90 pages or just one. By building a paginator we see a benefit in having a Presenter. One can test the business logic of the application, without testing the paginator itself, which is not, in itself, a business concern.
4. While building the paginator we need to know the total size of the collection. Instead of making another query to the model to ask for the size of the items or more wrongly requesting all the items in the collection and counting them in the code, we simply call a count() function on the DataSource that translates the request into an SQL query to the database. It seems we are working with a collection of data, but the adapter works as an interface for our queries making them only when needed.
5. We build the view, asking it to render itself.
6. The view again makes use of the fact that DataSource is an iterable component and translates the call for traversing of data into an SQL query into the database.
7. We respond to the user with a built view.

12 Django ↓Model-Template-View

1. The model layer is still in charge of data and persistence. The data get validated, processed, accessed and related to other data.
2. The template component is part of a presentation layer and decides how something should be displayed on a web page or other type of a document [77].
3. To make things a bit more confusing the view component is referred to in [77] as a business logic layer. This layer bridges the models and templates by calling models to fetch data and then displaying them in templates. The authors themselves note that this layer is commonly referred to as a controller layer, however in Django’s interpretation of MVC the view describes the data that get presented and decides which to present to the user and not just necessarily how the data look.

12.1 Generic Views

Figure 12.1 Ruby on Rails vs Django structure.

12.2 Data Validation

from django.db import models
​
class Category(models.model):
    title = models.CharField(max_length=250)
    slug = models.SlugField(unique=True)
    description = models.TextField()
    authors = models.ManyToManyField(Author)
    publisher = models.ForeignKey(Publisher)

12.3 Discussion of Django MTV

from django.contrib.auth.decorators import login_required
​
@login_required(redirect_field_name=’redirect_to’)
def my_view(request):
    ...

13 ↓Naked Objects Architecture

Object-Oriented Interfaces

13.1 Use-Case Controller

13.1.1 Overall Flow ≠ Behavior

Transaction Script

13.2 Domain model

Figure 13.1 Naked Objects, reproduced from [121].

Domain-Driven Design

Context and Use-Case Presenter

13.3 Discussion of Naked Objects

14 ↓Data, Context and Interaction

14.1 Problem

14.2 Solution

1. Data, that live in the domain objects that are rooted in domain classes.
2. Context that brings live objects into their positions in a scenario, giving context to objects through roles.
3. Interaction, that describes end-user algorithms in terms of the roles, both of which can be found in end users’ heads.

Figure 14.1 DCI architecture flow diagram.

1. Much like in a “ordinary” MVC architecture, an event from a user is received on the controller (called a Context).
2. The controller selects the models that we will need to work while processing the request.
3. The controller further selects the roles that the objects will need to play during the process.
4. Roles are injected, using perhaps aspects [M]  [M] Refer back to Aspect-oriented Programming in Section 5.2 ↑., into the models. The idea is to represent only data in the models while the roles encapsulate behavior.
5. Now that the controller has injected behavior into data, it invokes the first method on a model.
6. The models continue to interact with each other.

14.3 Discussion of DCI

Use-Case Controller

Presentation

Traits

“Adapt an object to different client’s needs through transparently attached role objects, each one representing roles the object has to play in that client’s context. The object manages its role set dynamically. By representing roles as individual objects, different contexts are kept separate and system configuration is simplified.”

15 Other Reviewed Approaches

15.1 ↓Presentation Abstraction Control

15.2 ↓Hierarchical Model-View-Controller

Open Reuse

	/**
	 * Authenticate user.
	 * @param string $username
	 * @param string $password
	 * @param string $token optional form token
	 * @return authenticationFail() or authenticationSuccess()
	 */
	public function authenticate($username, $password, $token=NULL) {
        // escape input
        $this->prepareUsername($username);
        $this->preparePassword($password);
​
        // if credentials provided and token is valid
        if (isset($username, $password) && ($this->validateToken($token))) {
			// select a matching row from a resource
			if ($this->matchUser()) {
                // save user into a session
                $_SESSION[self::SESSION_CREDENTIALS_STORAGE . APP_SALT] = $this->credentialsString();
                // success
                return $this->authenticateSuccess();
            }
		}
        // fail
        return $this->authenticateFail();
	}

15.3 ↓Dynamic Pipeline

Figure 15.2 Pipeline form and text edit in a database, reproduced from [92].

15.4 ↓Chiron-2 (C2)

15.5 ↓Model-View-ViewModel

1. Data Model, a component analogous to a data/business layer found in MVC or MVP.
2. ViewModel represents a layer that manages the state of the application by being bound to the view and its events. It provides data to the presentation layer in an appropriate form.
3. View is the presentation layer that communicates with the user.

Figure 15.3 ViewModel.

15.6 ↓Model Pipe View Controller

16 Summary of Part III, Patterns, Methods & Architectures

↓Model-View-Controller

↓Data Transfer Object

↓Model-View-Presenter

↓Model Adapter

Django ↓Model-Template-View

Naked Objects ↓Architecture

↓Data, Context and Interaction

Overview

Part IV. From Requirements to Code

17 Agile Methodologies

17.1 Agile Model Driven Development

18 Blog Example

18.1 Usage Model

As a (role) I want (something) so that (benefit). [43]

18.2 Architecture Envisioning

18.2.1 ↓Model-View-Controller

18.2.2 Presenter↓ and ↓Model Adapter

18.2.3 Domain Model

18.2.4 Context

18.2.5 Use-Case Controller

18.2.6 Validation

18.2.7 ↓Data Transfer Object

18.3 Initial Domain Model

18.3.1 Class Responsibility Collaborator cards

18.4 Development

1. As a blog visitor I want to see the blog articles from a specific category in a chronological order.
2. As an editor I want the ability to edit an article in a listing.

18.4.1 Layout

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta http-equiv="Content-Language" content="en" />
	<title>Blog</title>
</head>
<body>
    <?php echo $template; ?>
</body>
</html>

18.4.2 Template

<h1>Article listing</h1>
<?php
foreach($articles as $article) {
    echo "<h2>$article[’title’]</h2>";
    echo "<p>$article[’text’]</p>";
}

<h1>Article listing</h1>
<?php
foreach($articles as $article) {
    echo "<h2>$article[’title’]</h2>";
    echo ’<a href="edit/’ . $article[’id’] . ’">Edit</a>’;
    echo "<p>$article[’text’]</p>";
}

18.4.3 ↓Model-View-Presenter

<?php
final class BlogPresenter extends Presenter {
    public $contexts = array(’listing’ => array(’user’, ’blog’));
​
    public function userContext() {
        $this->user = new User();
    }
​
    public function blogContext() {
        $this->blog = new Blog($this->user->getRole());
    }
​
    public function listingUseCase() {
        ...
    }
}

Factory↓, Façade↓, Template Method↓, ↓Role Object

18.4.4 Use-Case Controller↓

<?php
final class BlogPresenter extends Presenter {
​
    ...
​
    public function listingUseCase() {
        $articles = $this->blog->getArticles();
        displayListing($articles);
    }
}

18.4.5 Presentation behavior

<?php
final class BlogPresenter extends Presenter {
​
    ...
​
    public function displayListing(array &$articles) {
        // inject data into a View through the Data Transfer Object
        $this->view->dto->articles = $articles;
        // choose which template to render
        switch($this->user) {
            case "editor":
                $this->view->render(’editorArticleListingTemplate.phtml’);
                break;
            case "visitor":
                $this->view->render(’visitorArticleListingTemplate.phtml’);
                break;
        }
    }
}

18.4.6 ↓Model Adapter

<?php
class Blog {
​
    ...
​
   /**
	 * Return articles in the blog system.
	 * @return array or an adapter based on the context!
	 */
    public function getArticles() {
        return $this->giveMeData();
    }
}

18.4.7 Presenter paginator

<?php
final class BlogPresenter extends Presenter {
​
    ...
​
    public function displayListing(array &$articles) {
        // first we need to specify a category that we are viewing
        $articles->where(’category="’ . $this->request->getCategory() . ’"’);
​
        // create a paginator component
        $paginator = new PresenterPaginator();
        // set size of articles per page
        $paginator->itemsPerPage = 10;
        // get the size of the collection
        $paginator->itemCount = count($articles);
        // set which page we are on now
        $paginator->currentPage = $this->request->getPage();
​
        // modify the adapter based on the paginator settings
        $articles->paginate($paginator->limit, $paginator->offset);
​
        // inject data into a View through the Data Transfer Object
        $this->view->dto->articles = $articles;
        // choose which template to render
        switch($this->user) {
            case "editor":
                $this->view->render(’editorArticleListingTemplate.phtml’);
                break;
            case "visitor":
                $this->view->render(’visitorArticleListingTemplate.phtml’);
                break;
        }
    }
}

1. First we are specifying a category the user (be it editor or visitor) has requested. We are setting a condition on the ↓Adapter returned to us from the model.
2. Next we are creating a framework component designed to deal with data pagination. Such a functionality is common and thus we should expect to have such component ready for use in the ↓Presenter.
3. We are applying a maximum size on each page in the data collection. This is clearly a presentation concern.
4. Next we are making use of the functionality Model Adapter↓ provides and counting the number of entries in the collection. It looks like we are working with an array, but the Adapter translates our request into an SQL query behind the scenes and gives us the result as needed.
5. We are then setting the current page we are on. This would come from the request.
6. Finally, the Adapter needs to be modified with conditions specifying which part of the collection we need.
7. The rest of the example stays the same.

18.4.8 Category case

18.4.8.1 Context

<?php
final class BlogPresenter extends Presenter {
    public $contexts = array(’listing’ => array(’user’, ’blog’));
​
    public function userContext() {
        $this->user = new User();
    }
​
    public function blogContext() {
        if (!$this->request->getCategory()) die(’Failed to provide a category!’);
        $this->blog = new Blog($this->user->getRole());
    }
​
    public function listingUseCase() {
        ...
    }
}

18.4.8.2 Use-Case Controller

<?php
final class BlogPresenter extends Presenter {
​
    ...
​
    public function listingUseCase() {
        // either display articles or give us a categories listing
        if (!$this->request->getCategory()) {
            $categories = $this->blog->getCategories();
            displayCategories($categories);
        } else {
            $articles = $this->blog->getArticles();
            displayListing($articles);
        }
    }
​
    ...
​
}

18.4.8.3 Presentation logic

<?php
final class BlogPresenter extends Presenter {
​
    ...
​
    public function displayListing(array &$articles) {
        // are we viewing articles from all categories or just one?
        if ($this->request->getCategory()) {
            $articles->where(’category="’ . $this->request->getCategory() . ’"’);
        }
​
        // create a paginator component
        $paginator = new PresenterPaginator();
        // set size of articles per page
        $paginator->itemsPerPage = 10;
        // get the size of the collection
        $paginator->itemCount = count($articles);
        // set which page we are on now
        $paginator->currentPage = $this->request->getPage();
​
        // modify the adapter based on the paginator settings
        $articles->paginate($paginator->limit, $paginator->offset);
​
        // inject data into a View through the Data Transfer Object
        $this->view->dto->articles = $articles;
        // choose which template to render
        switch($this->user) {
            case "editor":
                $this->view->render(’editorArticleListingTemplate.phtml’);
                break;
            case "visitor":
                $this->view->render(’visitorArticleListingTemplate.phtml’);
                break;
        }
    }
}

18.4.9 Validation

<?php
class Article implements Events {
​
   /**
	 * Attach an event callback.
	 * @param can be dummy object to switch events off.
	 */
    public function attachCallback(&$object) {
        $this->callback = $object;
    }   
​
   /**
	 * Callback object.
	 */
    public function eventCallback($code=null, $message=null) {
        $this->callback->raise($code, $message);
    }
​
    ...
​
    public function saveArticle($text) {
        // raise an event
        if (!isset($text)) $this->eventCallback(’VALIDATE_PRESENCE_OF_FAILED’, ’Article text has not been provided’);
        ...
        $this->saveObject();
    }
}

<?php
final class ArticlePresenter extends Presenter {
​
    ...
​
    public function saveUseCase() {
        try {
            $this->article->save(...);
            displayArticle(...);
        } catch (ArticleFormException $e) {
            displayForm(...);
        }
    }
​
    ...
​
}

19 Summary of Part IV, From Requirements to Code

<?php
final class BlogPresenter extends Presenter {
​
    /********************* Context *********************/
​
    public $contexts = array(’listing’ => array(’user’, ’blog’));
​
    public function userContext() {
        $this->user = new User();
    }
​
    public function blogContext() {
        $this->blog = new Blog($this->user->getRole());
    }
​
    /********************* Use-Case *********************/
​
    public function blogUseCase() {
        try {
            $this->blog->someAction(...);
            $articles = $this->blog->fetchSomeData();
            displayListing($articles);
        } catch (SomeSortOfException $e) {
            displayForm(...);
        }
    }
​
    /******************* Presentation *******************/
​
    public function displayListing(array &$articles) {
        ...
        $this->view->dto->articles = $articles;
        // choose which template to render
        switch($this->user) {
            case "editor":
                $this->view->render(’editorArticleListingTemplate.phtml’);
                break;
            case "visitor":
                $this->view->render(’visitorArticleListingTemplate.phtml’);
                break;
        }
    }
​
}

Figure 19.2 Final architecture.

1. View; that is to contain only a traversal of objects passed to it through DTO (Chapter 9 ↑), thus the template does not contain any logic calling models.
2. Controller; that will contain three steps a request goes through:
   1. First, model objects will be setup according to the context in which the request appears.
   2. Second, we describe the overall flow of events in a system by writing a use-case method.
   3. Third, at the end of the use-case, we identify which logic to use to present the result. Then, the Presenter would work with logic functionality as paginators, possibly adding conditions to Model Adapters as needed.
3. Model; is a component encompassing behaviors and data validation. We can identify three layers in a model:
   1. First, we would expect to find Role Objects, Template Methods, Factories and other approaches used to construct objects in a certain context. These objects can be likened to Aggregate Root entities in Domain-Driven Design [55] that cluster domain objects that will be treated from the use-case as one unit for the purposes of data exchange. [99] would call this functionality as being a Creator↓ pattern in general.
   2. Second, we have the actual domain models containing behaviors, and the business logic.
   3. Third, we would abstract away all persistence layer connections from domain models to a further layer that handles them, an ORM.

Part V. Project Conclusions

20 Conclusion

1. Identify the concerns a web application architecture has to handle and the different forces put on it.
2. Identify approaches used to describe web application architectures.
3. Evaluate critically the patterns, models and approaches relevant to a development of a web system that adhere to sound software engineering principles in the web domain.
4. Explore the merit of the different approaches identified in 3. and their synergic collaboration and effect.
5. Formulate architecture recommendations for industry web developers and web engineering academics alike.

20.1 Research Objectives: Summary of Findings and Conclusions

Identify the concerns a web application architecture has to handle and the different forces put on it

Identify approaches used to describe web application architectures.

Evaluate critically the patterns, models and approaches relevant to a development of a web system that adhere to sound software engineering principles in the web domain.

Explore the merit of the different approaches identified and their synergic collaboration and effect.

<?php
​
switch($_GET[’route’]) {
    case "home":
        controller();
        break;
    default:
        die("Page not found");
}
​
function getData() {
    return ’Lorem ipsum dolor sit’;
}
​
function controller() {
    $data = getData();
    view($data);
}
​
function view($data) {
    echo ’<html><head><title>Template</title></head><body>’ . $data . ’</body></html>’;
}

Formulate architecture recommendations for industry web developers and web engineering academics alike.

20.2 Recommendations & Future Work

1. For researchers in the subject to not quote generic variants of patterns or variants that are applied in a different domain. Patterns are now so varied that they need to be described and cited in their specific version, not a generic one.
2. Furthermore, as one pattern is not enough to describe even an overall system architecture, combinations of patterns and approaches need to be studied. We would like to make a point that mentioning that “pattern X” can be often found and used in conjunction with “pattern Y” is insufficient, as the combination of these patterns creates and presents a unique set of qualitative traits. A disadvantage of one pattern can be leveraged by using another and vice versa. Serious discussion on this topic needs to start.
3. Following from the previous point, a web engineering field should focus on providing help for the developers in the field and represent “engineering” in the domain of computer science. What we mean is that the domain can build up to date repositories that describe pattern variants and their collaborative effects. We therefore suggest that the next steps should be as follows:
   1. A first stage would be to find successful architectures in the field and describe them in terms of patterns (after all a pattern is a solution to a problem) used. Such projects could, in the first instance, be taken from open-source repositories that are plentiful [W]  [W] GitHub, Google Code, Bitbucket, Sourceforge, Launchpad, Snipplr etc.. At the moment, the task of pattern identification cannot be fully done automatically [X]  [X] [32] presents a verification language for some design patterns implemented in Java..
   2. In a second stage, the overall architecture could be rated in terms of qualitative benefits derived. This would mean that one could see which approaches were used to tackle a particular problem, and would help developers in the field better gauge the good from the bad.
   3. A third stage would reflect back on this knowledge base and would identify which patterns, in the long run, needlessly increased the complexity of a system or represented a non-reusable solution. Then, experts in the field could suggest alternative solutions. Perhaps, approaches such as artificial neural networks could be trained to recognize patterns in future systems based on a large sample which would be present at this stage.

20.3 Contribution to Knowledge

20.4 Finally

Appendixes

A Further Discussions

A.1 HTML5

1. A a basic relational database based on SQLite:

   var db = window.openDatabase("Database Name", "Database Version");
   db.transaction(function(tx) {
   	tx.executeSql("SELECT * FROM test", [], successCallback, errorCallback);
   });
   
2. Web Sockets that allow the web server to push new data to the client browser.
3. Notifications that display a desktop notification rather than just a browser notification. Currently applications have to change the <title> of the browser window or play a sound to notify the user.

A.2 Web Applications Release & Deployment

Figure A.1 Attlasian Bamboo Release & Deployment Flow.

A.3 Response types

[{
	"text":"Hello, this is a new message",
	"type":"text",
	"user":"Jerry S."
}]

<tr>
	<td class="user text our">Jerry S.</td>
	<td class="body text our">Hello, this is a new message
		<div id="highlight_6" onclick="highlightMessage(’6’);return false;" class="highlight"><a href=""></a></div>
	</td>
</tr>

Glossary

Index

Adapter: ↑, ↑, ↑, ↑, ↑, ↑, ↑

Autonomous view: ↑

Business Helper: ↑, ↑

Chiron-2: ↑

Command: ↑

Composite: ↑

Composite Message: ↑

Compound Design: ↑, ↑

Creator: ↑

Data Transfer Object: ↑, ↑, ↑, ↑, ↑, ↑

Data, Context and Interaction: ↑, ↑, ↑, ↑

Decorator: ↑, ↑, ↑, ↑

Document-View: ↑

Dynamic Pipeline: ↑

Event-Listener: ↑

Factory: ↑, ↑, ↑, ↑, ↑, ↑

Façade: ↑, ↑, ↑, ↑

Front Controller: ↑

Hierarchical Model-View-Controller: ↑

Intercepting Filter: ↑, ↑, ↑

Mediator: ↑, ↑

Model Adapter: ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑

Model Pipe View Controller: ↑

Model-Controller: ↑

Model-Template-View: ↑, ↑, ↑

Model-View: ↑

Model-View-Controller: ↑, ↑, ↑, ↑, ↑, ↑

Model-View-Controller-User: ↑

Model-View-Presenter: ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑

Model-View-ViewModel: ↑, ↑, ↑

Naked Objects: ↑, ↑, ↑, ↑, ↑, ↑

Observer: ↑, ↑, ↑, ↑, ↑, ↑

Passive Screen: ↑

Passive View: ↑, ↑

Pipes & Filters: ↑

Presentation Abstraction Control: ↑

Presentation Model: ↑

Presenter: ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑

Presenter First: ↑

Proxy: ↑, ↑

Publisher-Subscriber: ↑

Role Object: ↑, ↑, ↑, ↑

Strategy: ↑, ↑, ↑

Supervising Controller: ↑, ↑, ↑, ↑

Template Method: ↑, ↑, ↑, ↑, ↑, ↑, ↑

Thing-Model-View-Editor: ↑

Transaction Script: ↑

Use-Case Controller: ↑, ↑, ↑, ↑, ↑, ↑, ↑, ↑

View-Controller: ↑

ViewModel: ↑