1. Lecture 11
Application Architecture

2. Reading
 Fowler 2, 3, 4, 9, 10 , 11, 14, 15
 Fowler 8

3. Agenda




Layering
Application Architecture
Play! implementation
Introduction to REST

4. Layering

5. Layering
 Software systems can get complicated
– Abstractions are needed
 Provides abstraction by separating computer
systems in layers
– Higher layers use services from
lower layers
– Each layer has dedicated task
and hides complexity from upper
layers

6. Three Layers
 Presentation Layer for the User Interface
 Domain Layer for the domain logic
 Data Source Layer for the data access
Client
Domain
Client
– Separation of concern
Data Source

7. Presentation Layer
 Consideration
– Separating the Presentation Logic from the Domain
Logic
– Simple vs. Rich user interface
– Should content be editable frequently

8. User Interfaces
 Clear separation of concerns is important
– Define the Presentation Logic
– Design the domain layer so the presentation can get
the information needed
– Semantics – or the meaning of things is important
– Presentation logic must avoid making assumptions on
the domain – the semantics should be a part of the
domain
• Use Data Transfer Objects to store semantics

9. Client Types
 Native OS Applications
– Windows, iOS, Android, Linux
 Embedded
– Run inside Web Browsers
– Flash, Java Applets
 Interactive Web Applications
– HTML with JavaScript
 HTML Presentation in Browsers
– Simple HTML

10. Content Delivery
 Native, Embedded and Interactive Web Apps
– Require HTTP API call for dynamic content
– For example SOAP, REST with Json or XML
 HTML Presentation in Browsers
– Server side generated

11. Content Type
 Static Content such as graphic assets, doesn’t
change frequently
 Editable Content such as text, layout, mashedup content, editable by content
owners, frequently
 Dynamic Content stored in database and
manipulated by the domain logic

12. Content Management Systems
 Content is separated form the Enterprise system
– Managed by CMS software with its own database
– HTTP API calls for dynamic content from the
enterprise system
CLIENT
Web Browser
HTML
JavaScript
HTTP/REST/Json
Enterprise
Application
CMS
Editable
content
OPERATOR
Dynamic
content
Static
content
Static
content

13. Domain Layer
 Where is the domain logic?
– Application Servers
– Lightweight Containers

14. Application Servers
 Domain Components are deployed on
Application Servers
– Distributed Multi-tiered Applications
– Example:
• Web Servers, EJB Servers

15. Lightweight Containers
 Assemble components from different projects
into a cohesive application
– Wiring is done with “Inversion of Control” - config
– Provide life-cycle management of objects
– Provide context
Web Server
Lightweight Container
Web Browser
(User Interface)
Web Layer
Web Browser
(User Interface)
Domain
Layer
Data
Source
Layer
Database

16. Data Source Layer
 How to create the mapping from the domain to
the Data Source Layer
– Gateways with no domain logic
– Records managed with some domain logic
– Data Mappers

17. Data Source Layer
 Domain Model uses gateway
Domain
Layer
Data
Source
Layer

18. Object Relational Mapping (ORM)
 Use a mapping layer to map between objects
and tables
– Mapping a data representation from an object model
to a relational data model with a SQL-based schema
 Mapping requires
metadata
– XML
 Authoring and
maintaining
metadata is less work than maintaining SQL

19. The Big Picture
CMS
Client
Web
Server
REST
Domain
Data
Source
DB

20. The Big Picture in SOA
CMS
Frameworks
Frameworks
Client
Web
Server
REST
Web
Server
REST
SERVICE
Data
Source
DB
SERVICE
Data
Source
DB
Domain
Domain

21. Application Architecture

22.  Advice is a dangerous gift
– There are no right answers
– “Use the advice to prod your thinking, but don’t use it
as a replacement for your thinking”

23. Three Layers
 Presentation Layer for the User Interface
 Domain Layer for the domain logic
 Data Source Layer for the data access
Presentation
Layer
Domain
– What patterns to use?
Data Source

24. Domain Layer
 Transaction Script
 Domain Model
 Table Module

25. Domain Layer
 Transaction Script
– Procedural
– Encapsulates the logic of each transaction
– Works well for systems that are transactional in
nature
 Drawbacks
– Does not handle complexity of logic
– Code duplications

26. Domain Layer
 Domain Model
– Works nicely for any type of domain logic
– Flexibility in creating an object oriented classes that
use abstractions and polymorphism
– Beautiful code
 Drawbacks
– Learning curve – understanding the model
– Requires skills
– Doesn’t map easily to relational database

27. Domain Layer
 Table Module
– Works well for data driven applications
– Fits well with relational databases
– Requires Record Set functionality
 Drawbacks
– Structured around the database
– Needs tooling support, for example Record Set
– Can become dependent on the environment

28. Data Source Layer
 Data Source for Transaction Script
–
–
–
–
Fits well to use the Gateway patterns
Row Data Gateway or Table Data Gateway
Depends on the applications
If the transactions are dealing with each row per
transactions, then Row Data Gateway works
– If working with tables, Table Data Gateway works

29. Data Source Layer
 Data Source for Table Module
– Table Module requires good support from Record
Set
– Table Data Gateway fits this well

30. Data Source Layer
 Data Source for Domain Model
– If the Domain Model is fairly simple, and maps the
database, Active Record works well
– If you want to provide abstraction the gateway
patterns become better choice, Row Data Gateway
and Table Data Gateway
– If things get more complication and there is need to
keep the model independent from the data
source, Data Mapper should be considered

31. Model View Controller
 For all types MVC architectural patterns applies
 Web Frameworks are usually implemented
using the Front Controller pattern
 Each request has an Action or a Controller
 Views are handle by Template View

32. The Big Picture
Domain Layer
Presentation
Layer
Service
Layer
Data Source
DB
Domain

33. QUIZ
We have a relatively simple domain logic that maps nicely to
the data schema, and we have good tools for Record Set
handling. What Domain Layer pattern would make sense?
A)
B)
C)
✔ D)
Service Layer
Domain Model
Transaction Script
Table Module

34. Play! Framework
34

35. Exercise
 Design Web Application RuNews
– Front page displays RSS news items
– Content read with ImportContentProcess
– User can sign up and login

36. Overivew
Controller
Service Layer
Table Data
Gateway
Domain Model
users
View
routes
ApplicationConext.xml

37. Signup
 As a user, I want to be able to sign up
Registration
Fields: name, username, password, email
Validtaion:
all fields are required
username must be at least 4 characters
password must be confirmed (typed in twice)

39. Play setup
 Project is created: RuNews
 Structure
controllers
is.ru.honn.news
views
39

40. The Database
 Table users
CREATE TABLE users
(
id int Identity (1, 1) primary key NOT NULL,
name varchar(128),
username varchar(128) unique,
password varchar(128),
email varchar(128),
)
40

41. Application.java
package controllers;
import play.*;
import play.mvc.*;
import views.html.*;
public class Application extends Controller
{
public static Result index()
{
return ok(index.render());
}
}
41

42. index
 View is views/index.scala.html
@main(Html("RuNews")) {
<h2>Registration</h2>
<p>
Here you can sign up: <a class="btn”
href="@routes.SignUp.blank">Sign up</a>
</p>
}
 Compiled: views/html/index
42

43. Routing
 conf/routes contains the routing information
# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~
# Home page
GET
/
controllers.Application.index()
# Sign Up
GET
/signup
POST
/signup
controllers.SignUp.blank()
controllers.SignUp.submit()
# Map static resources from the /public folder to the /assets URL path
GET
/assets/*file
controllers.Assets.at(path="/public", file)
43

44. RuNews Example
 User
public class User
{
protected int id;
protected String name;
protected String username;
protected String password;
protected String email;
public User()
{
}
public User(int id, String name, String username, String password,
String email)
{
this.id = id;
this.name = name;
44

45. RuNews Example
 UserService is a Service Layer interface
public interface UserService
{
public int signup(User user);
public User login(String username, String password);
public void setUserDataGateway(UserDataGateway userDataGateway);
}
 UserServiceData contains the implementation
45

46. Adding Domain and Data Layers
 Implementation of Service
Layer, Domain and Data
Source Layers added
– Added as is
– Should be in model
46

47. Adding Domain and Data Layers
 ApplicationContext.xml added to conf
– Drop data.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="userService" class="is.ru.honn.news.service.UserServiceData">
<property name="userDataGateway" ref="userDataGateway"/>
</bean>
<bean id="userDataGateway" class="is.ru.honn.news.data.UserData">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="net.sourceforge.jtds.jdbc.Driver"/>
<property name="url" value="jdbc:jtds:sqlserver://hrnem.ru.is:1433"/>
47

48. Adding Domain and Data Layers
 Table Data Gateway injected into service
public class UserServiceData implements UserService
{
RuDataAccessFactory factory;
UserDataGateway userDataGateway;
public UserServiceData()
{
}
public void setUserDataGateway(UserDataGateway UserDataGateway)
{
this.userDataGateway = UserDataGateway;
}
48

49. RuNews Example
 Signup is a Controller
import views.html.signup.*;
import is.ru.honn.news.domain.UserRegistration;
public class SignUp extends Controller
{
final static Form<UserRegistration> signupForm
= Form.form(UserRegistration.class);
public static Result blank()
{
return ok(form.render(signupForm));
}
49

50. RuNews Example
 Signup is a Controller
public static Result submit()
{
Form<UserRegistration> filledForm = signupForm.bindFromRequest();
...
if (filledForm.hasErrors()) {
return badRequest(form.render(filledForm));
}
else {
User created = filledForm.get();
ApplicationContext ctx = new FileSystemXmlApplicationContext
("/conf/ApplicationContext.xml");
UserDataGateway userDataGateway =
(UserDataGateway)ctx.getBean("userDataGateway");
userDataGateway.addUser((User)created);
return ok(summary.render(created));
}
}
}
50

51. RuNews Example
 form.scala.html is the view
@(signupForm: Form[is.ru.honn.news.domain.UserRegistration])
@import helper._
@import helper.twitterBootstrap._
@title = {
Sign Up
}
@main(title, nav = "signup") {
@helper.form(action = routes.SignUp.submit) {
<fieldset>
<legend>Account informations</legend>
@inputText(
signupForm("name"),
'_label -> "Name",
'_help -> "Please enter your name.",
'_error -> signupForm.globalError
)
51

52. RuNews Example
 form.scala.html is the view
@inputText(
signupForm("username"),
'_label -> "Username",
'_help -> "Please choose a valid username.",
'_error -> signupForm.globalError
)
@inputText(
signupForm("email"), '_label -> "Email",
'_help -> "Enter a valid email address."
)
@inputPassword(
signupForm("password"),
'_label -> "Password",
'_help -> "A password must be at least 6 characters. "
)...
</fieldset>
52

53. RuNews Example
 forms.scala.html is the view
<fieldset>
@checkbox(
signupForm("accept"),
'_label -> None, '_text -> "You agree the Terms and conditions",
'_showConstraints -> false
)
</fieldset>
<div class="actions">
<input type="submit" class="btn primary" value="Sign Up">
<a href="@routes.Application.index" class="btn">Cancel</a>
</div>
}
}
53

54. RuNews Example
 summary.scala.html displayes the user
@(user: is.ru.honn.news.domain.User)
@main(Html("Account created!"), nav = "signup") {
<h2>Your account:</h2>
<p>Name: @user.getName()</p>
<p>Username: @user.getUsername()</p>
<p>Email: @user.getEmail()</p>
}
54

55. 55