Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Download to read offline

L11 Application Architecture

Download to read offline

Now that we have looked several design patterns, from the databases to web presentation, we are now ready to look at the application as a whole. In this lecture we examine the considerations we face when creating an application architecture and we look at each of the three layers.

The lecture presents one way of designing enterprise applications. The goal is to create scalable services.

We also look at the Play framework in more detail and look at REST.

Related Books

Free with a 30 day trial from Scribd

See all

L11 Application Architecture

  1. 1. Lecture 11 Application Architecture
  2. 2. Reading  Fowler 2, 3, 4, 9, 10 , 11, 14, 15  Fowler 8
  3. 3. Agenda     Layering Application Architecture Play! implementation Introduction to REST
  4. 4. Layering
  5. 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. 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. 7. Presentation Layer  Consideration – Separating the Presentation Logic from the Domain Logic – Simple vs. Rich user interface – Should content be editable frequently
  8. 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. 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. 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. 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. 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. 13. Domain Layer  Where is the domain logic? – Application Servers – Lightweight Containers
  14. 14. Application Servers  Domain Components are deployed on Application Servers – Distributed Multi-tiered Applications – Example: • Web Servers, EJB Servers
  15. 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. 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. 17. Data Source Layer  Domain Model uses gateway Domain Layer Data Source Layer
  18. 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. 19. The Big Picture CMS Client Web Server REST Domain Data Source DB
  20. 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. 21. Application Architecture
  22. 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. 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. 24. Domain Layer  Transaction Script  Domain Model  Table Module
  25. 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. 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. 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. 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. 29. Data Source Layer  Data Source for Table Module – Table Module requires good support from Record Set – Table Data Gateway fits this well
  30. 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. 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. 32. The Big Picture Domain Layer Presentation Layer Service Layer Data Source DB Domain
  33. 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. 34. Play! Framework 34
  35. 35. Exercise  Design Web Application RuNews – Front page displays RSS news items – Content read with ImportContentProcess – User can sign up and login
  36. 36. Overivew Controller Service Layer Table Data Gateway Domain Model users View routes ApplicationConext.xml
  37. 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)
  38. 38. Play setup  Project is created: RuNews  Structure controllers views 39
  39. 39. 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
  40. 40. package controllers; import play.*; import play.mvc.*; import views.html.*; public class Application extends Controller { public static Result index() { return ok(index.render()); } } 41
  41. 41. 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
  42. 42. 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"/public", file) 43
  43. 43. 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) { = id; = name; 44
  44. 44. 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
  45. 45. Adding Domain and Data Layers  Implementation of Service Layer, Domain and Data Source Layers added – Added as is – Should be in model 46
  46. 46. Adding Domain and Data Layers  ApplicationContext.xml added to conf – Drop data.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <bean id="userService" class=""> <property name="userDataGateway" ref="userDataGateway"/> </bean> <bean id="userDataGateway" class=""> <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://"/> 47
  47. 47. 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
  48. 48. RuNews Example  Signup is a Controller import views.html.signup.*; import; public class SignUp extends Controller { final static Form<UserRegistration> signupForm = Form.form(UserRegistration.class); public static Result blank() { return ok(form.render(signupForm)); } 49
  49. 49. 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
  50. 50. RuNews Example  form.scala.html is the view @(signupForm: Form[]) @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
  51. 51. 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
  52. 52. 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
  53. 53. RuNews Example  summary.scala.html displayes the user @(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
  54. 54. 55
  • gilbertoca

    Jan. 17, 2014

Now that we have looked several design patterns, from the databases to web presentation, we are now ready to look at the application as a whole. In this lecture we examine the considerations we face when creating an application architecture and we look at each of the three layers. The lecture presents one way of designing enterprise applications. The goal is to create scalable services. We also look at the Play framework in more detail and look at REST.


Total views


On Slideshare


From embeds


Number of embeds