Object Oriented Methods Architectural Patterns 2 Spring 2009

  • Slides: 54
Download presentation
Object Oriented Methods Architectural Patterns 2 Spring 2009 Computer Science Department, TUC-N

Object Oriented Methods Architectural Patterns 2 Spring 2009 Computer Science Department, TUC-N

Midterm exam • Week 7 [6 -10 April] • Final Exam = 50% from

Midterm exam • Week 7 [6 -10 April] • Final Exam = 50% from the Final Grade • Midterm Exam = 30% from the Final Exam • Can be re-taken in the Exam Session Spring 2009 Computer Science Department, TUC-N

Content • Patterns for Enterprise Application Architecture [Fowler] – Domain Layer Patterns • •

Content • Patterns for Enterprise Application Architecture [Fowler] – Domain Layer Patterns • • Transaction Script Domain Model Table Module Active Record – Data Source Patterns • Row Data Gateway • Table Data Gateway • Data Mapper Spring 2009 Computer Science Department, TUC-N

References • Martin Fowler et. al, Patterns of Enterprise Application Architecture, Addison Wesley, 2003

References • Martin Fowler et. al, Patterns of Enterprise Application Architecture, Addison Wesley, 2003 [Fowler] • Univ. of Aarhus Course Materials • Univ. of Utrecht Course Materials Spring 2009 Computer Science Department, TUC-N

Patterns for Enterprise Applications [Fowler] • • • Persistent data Volume of data Concurrent

Patterns for Enterprise Applications [Fowler] • • • Persistent data Volume of data Concurrent access Complicated user interface Integration with other applications – Conceptual dissonance • Business logic Spring 2009 Computer Science Department, TUC-N

Enterprise applications • Example: B 2 C online retailer – High volume of users:

Enterprise applications • Example: B 2 C online retailer – High volume of users: scalability • Example: processing of leasing agreements – Complicated business logic – Rich-client interface – Complicated transaction behavior • Example: expense tracking for small company Spring 2009 Computer Science Department, TUC-N

Principal layers • See pattern Layers in [POSA] • Here: applied to enterprise applications

Principal layers • See pattern Layers in [POSA] • Here: applied to enterprise applications • Presentation logic – Interaction with user – Command-line or rich client or Web interface • Domain logic – Validation of input and calculation of results • Data source logic – Communication with database and other applications Spring 2009 Computer Science Department, TUC-N

Domai Presentati Data Source on n EA Patterns Page Controller Template View Front Controller

Domai Presentati Data Source on n EA Patterns Page Controller Template View Front Controller Transform View Transaction Script Active Record Table Module Row Data Gateway Table Data Gateway Spring 2009 Domain Model Data Mapper Computer Science Department, TUC-N

Domain Logic (Layer) • “… also referred to as business logic. … It involves

Domain Logic (Layer) • “… also referred to as business logic. … It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch …” [Fowler] Spring 2009 Computer Science Department, TUC-N

Organizing the Domain Logic • Key architectural decisions, which influence structure of other layers.

Organizing the Domain Logic • Key architectural decisions, which influence structure of other layers. • Pure patterns – Transaction Script – Domain Model • Hybrid patterns – Active Record – Table Module. Spring 2009 Computer Science Department, TUC-N

Domai Data Source n Presentation Domain Logic Patterns Transaction Script Table Module Active Record

Domai Data Source n Presentation Domain Logic Patterns Transaction Script Table Module Active Record Table Data Gateway Row Data Gateway Spring 2009 Computer Science Department, TUC-N Page Controller Template View Front Controller Transform View Domain Model Data Mapper

Transaction Script Fowler: A TS organizes the business logic primarily as a single procedure

Transaction Script Fowler: A TS organizes the business logic primarily as a single procedure where each procedure handles a single request from the presentation. The TS may make calls directly to the DB or through a thin DB wrapper. Think of a script for: a use case or business transaction. Implementation can be – Shared among subroutines. – Subroutines can be used by more than one script Spring 2009 Computer Science Department, TUC-N

Transaction Script • … is essentially a procedure that takes the – – –

Transaction Script • … is essentially a procedure that takes the – – – input from the presentation, processes it with validations and calculations, stores data in the database, (invokes any operations from other systems, and) replies with more data to the presentation perhaps doing more calculation to help organize and format the reply data. [Fowler] Spring 2009 Computer Science Department, TUC-N

TS Features • Business logic is organized by procedures • Each procedure handles a

TS Features • Business logic is organized by procedures • Each procedure handles a single transaction • Transaction: well-defined endpoint • Must be complete on all-or-nothing basis • Makes call directly to the database • May be organized as: – a separate class/TS (Command pattern) – several TS/class Spring 2009 Computer Science Department, TUC-N

Example - Revenue Recognition (RR) • Revenue recognition is a common problem in business

Example - Revenue Recognition (RR) • Revenue recognition is a common problem in business systems. – when you can actually count the money you receive on your accounting books. • E. g. selling a S/W package $120 today – Book $40 today, – $40 in 30 days, – $40 in 60 days. [Fowler] Spring 2009 Computer Science Department, TUC-N

RR for Simple. Soft • Company named Simple. Soft • Sells S/W: – Word

RR for Simple. Soft • Company named Simple. Soft • Sells S/W: – Word processor, – Database, – Spreadsheet. • Contract: covers only one product. • Revenue recognition varies per product type. Spring 2009 Computer Science Department, TUC-N

TS: Calculating Revenue Recognitions Spring 2009 Computer Science Department, TUC-N

TS: Calculating Revenue Recognitions Spring 2009 Computer Science Department, TUC-N

Implementation • Database CREATE TABLE products (ID int primary key, name varchar, type varchar)

Implementation • Database CREATE TABLE products (ID int primary key, name varchar, type varchar) CREATE TABLE contracts (ID int primary key, product int, revenue decimal, date. Signed date) CREATE TABLE revenue. Recognitions (contract int, amount decimal, recognized. On date, PRIMARY KEY (contract, recognized. On)) Spring 2009 Computer Science Department, TUC-N

Implementation - calculate the amount of recognition due by a particular day: - select

Implementation - calculate the amount of recognition due by a particular day: - select the appropriate rows in the revenue recognitions table, - sum up the amounts. Spring 2009 Computer Science Department, TUC-N

Gateway class Gateway. . . public Result. Set find. Recognitions. For(long contract. ID, Mf.

Gateway class Gateway. . . public Result. Set find. Recognitions. For(long contract. ID, Mf. Date asof) throws SQLException { Prepared. Statement stmt = db. prepare. Statement(find. Recognitions. Statement); stmt =db. prepare. Statement(find. Recognitions. Statement); stmt. set. Long(1, contract. ID); stmt. set. Date(2, asof. to. Sql. Date()); Result. Set result = stmt. execute. Query(); return result; } private static final String find. Recognitions. Statement = "SELECT amount " + " FROM revenue. Recognitions " + " WHERE contract = ? AND recognized. On <= ? "; private Connection db; Spring 2009 Computer Science Department, TUC-N

Recognition. Service class Recognition. Service. . . public Money recognized. Revenue(long contract. Number, Mf.

Recognition. Service class Recognition. Service. . . public Money recognized. Revenue(long contract. Number, Mf. Date as. Of) { Money result = Money. dollars(0); try { Result. Set rs = db. find. Recognitions. For(contract. Number, as. Of); while (rs. next()) { result = result. add(Money. dollars(rs. get. Big. Decimal("amount"))); } return result; } catch (SQLException e) { throw new Application. Exception (e); } } Spring 2009 Computer Science Department, TUC-N

Analysis • Strenghths – Simplicity • Weaknesses – complicated transaction logic – duplicated logic

Analysis • Strenghths – Simplicity • Weaknesses – complicated transaction logic – duplicated logic Spring 2009 Computer Science Department, TUC-N

Domain Model (EA Pattern) Fowler: An object model of the domain that incorporates both

Domain Model (EA Pattern) Fowler: An object model of the domain that incorporates both behaviour and data. A DM creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line in an order form. Spring 2009 Computer Science Department, TUC-N

Domain Model (EA Pattern) • Realization (via design classes) of UML Domain Model (conceptual

Domain Model (EA Pattern) • Realization (via design classes) of UML Domain Model (conceptual classes). – E. g. person, book, shopping cart, task, sales line item, … • Domain Model classes contain – Logic for handling validations and calculations. • E. g. a shipment object – calculate the shipping charge for a delivery. • Can still have routines for actions (e. g. checkout) – but they quickly delegate to method in Domain Model. Spring 2009 Computer Science Department, TUC-N

DM Features • Business logic is organized as an OO model of the domain

DM Features • Business logic is organized as an OO model of the domain – Describes both data and behavior – Different from database model • Process, multi-valued attributes, inheritance, design patterns • Harder to map to the database • Risk of bloated domain objects Spring 2009 Computer Science Department, TUC-N

RR for SS: Conceptual Model Spring 2009 Computer Science Department, TUC-N

RR for SS: Conceptual Model Spring 2009 Computer Science Department, TUC-N

Domain Model: Calculating Revenue Recognitions Spring 2009 Computer Science Department, TUC-N

Domain Model: Calculating Revenue Recognitions Spring 2009 Computer Science Department, TUC-N

Enhancement: e. g. New Revenue Recognition Strategy • Transaction Script: – New conditional, or

Enhancement: e. g. New Revenue Recognition Strategy • Transaction Script: – New conditional, or – New subroutine. • Domain Model: – Create new Rev. Recog. Strategy class. Spring 2009 Computer Science Department, TUC-N

RR problem with Domain Model Spring 2009 Computer Science Department, TUC-N

RR problem with Domain Model Spring 2009 Computer Science Department, TUC-N

Implementation class Revenue. Recognition. . . private Money amount; private Mf. Date date; public

Implementation class Revenue. Recognition. . . private Money amount; private Mf. Date date; public Revenue. Recognition(Money amount, Mf. Date date) { this. amount = amount; this. date = date; } public Money get. Amount() { return amount; } boolean is. Recognizable. By(Mf. Date as. Of) { return as. Of. after(date) || as. Of. equals(date); } Spring 2009 Computer Science Department, TUC-N

Contract class Contract. . . private List revenue. Recognitions = new Array. List(); public

Contract class Contract. . . private List revenue. Recognitions = new Array. List(); public Money recognized. Revenue(Mf. Date as. Of) { Money result = Money. dollars(0); Iterator it = revenue. Recognitions. iterator(); while (it. has. Next()) { Revenue. Recognition r = (Revenue. Recognition) it. next(); if (r. is. Recognizable. By(as. Of)) result = result. add(r. get. Amount()); } return result; } Spring 2009 Computer Science Department, TUC-N

Introducing strategies… class Contract. . . private Product product; private Money revenue; private Mf.

Introducing strategies… class Contract. . . private Product product; private Money revenue; private Mf. Date when. Signed; private Long id; public Contract(Product product, Money revenue, Mf. Date when. Signed) { this. product = product; this. revenue = revenue; this. when. Signed = when. Signed; } Spring 2009 Computer Science Department, TUC-N

Introducing strategies … class Product. . . private String name; private Recognition. Strategy recognition.

Introducing strategies … class Product. . . private String name; private Recognition. Strategy recognition. Strategy; public Product(String name, Recognition. Strategy recognition. Strategy) { this. name = name; this. recognition. Strategy = recognition. Strategy; } public static Product new. Word. Processor(String name) { return new Product(name, new Complete. Recognition. Strategy()); } public static Product new. Spreadsheet(String name) { return new Product(name, new Three. Way. Recognition. Strategy(60, 90)); } public static Product new. Database(String name) { return new Product(name, new Three. Way. Recognition. Strategy(30, 60)); } Spring 2009 Computer Science Department, TUC-N

Introducing strategies … class Recognition. Strategy. . . abstract void calculate. Revenue. Recognitions(Contract contract);

Introducing strategies … class Recognition. Strategy. . . abstract void calculate. Revenue. Recognitions(Contract contract); class Complete. Recognition. Strategy. . . void calculate. Revenue. Recognitions(Contract contract) { contract. add. Revenue. Recognition(new Revenue. Recognition(contract. get. Revenue(), contract. get. When. Signed())); } class Three. Way. Recognition. Strategy. . . Spring 2009 Computer Science Department, TUC-N

Introducing strategies class Contract. . . public void calculate. Recognitions() { product. calculate. Revenue.

Introducing strategies class Contract. . . public void calculate. Recognitions() { product. calculate. Revenue. Recognitions(this); } class Product. . . void calculate. Revenue. Recognitions(Contract contract) { recognition. Strategy. calculate. Revenue. Recognitions( contract); } Spring 2009 Computer Science Department, TUC-N

Choosing a Domain Logic Pattern • Which one to choose? – Influenced by the

Choosing a Domain Logic Pattern • Which one to choose? – Influenced by the complexity of domain logic. Spring 2009 Computer Science Department, TUC-N

Choosing Between TS & DM • Application is simple access to data sources Transaction

Choosing Between TS & DM • Application is simple access to data sources Transaction Script, (or Active Record, Table Module) • Significant amount of business logic Domain Model • TS is simpler: – Easier and quicker to develop and maintain. – But can lead to duplication in logic / code. Spring 2009 Computer Science Department, TUC-N

TS DM • DM – difficult access to relational DB • Easier to refactor

TS DM • DM – difficult access to relational DB • Easier to refactor TS DM than DM TS. (? ? ) Spring 2009 Computer Science Department, TUC-N

Data Source Patterns • Pure patterns. – Row Data Gateway, – Table Data Gateway,

Data Source Patterns • Pure patterns. – Row Data Gateway, – Table Data Gateway, – Data Mapper –… • Hybrid patterns. – Active Record – Table Module Spring 2009 Computer Science Department, TUC-N

Domai Data Source n Presentation Data Source Patterns Transaction Script Table Module Active Record

Domai Data Source n Presentation Data Source Patterns Transaction Script Table Module Active Record Table Data Gateway Row Data Gateway Spring 2009 Computer Science Department, TUC-N Page Controller Template View Front Controller Transform View Domain Model Data Mapper

Table Module • Provide a single object for all the behavior on a table

Table Module • Provide a single object for all the behavior on a table Spring 2009 Computer Science Department, TUC-N

Features • Organizes domain logic with one class per table • Table Module has

Features • Organizes domain logic with one class per table • Table Module has no notion of an identity for the objects that it's working with ÞId references are necessary Spring 2009 Computer Science Department, TUC-N

TM in the RR example Spring 2009 Computer Science Department, TUC-N

TM in the RR example Spring 2009 Computer Science Department, TUC-N

Typical interactions for TM Spring 2009 Computer Science Department, TUC-N

Typical interactions for TM Spring 2009 Computer Science Department, TUC-N

RR problem with TM Spring 2009 Computer Science Department, TUC-N

RR problem with TM Spring 2009 Computer Science Department, TUC-N

Implementation (C#) class Table. Module. . . protected Data. Table table; protected Table. Module(Data.

Implementation (C#) class Table. Module. . . protected Data. Table table; protected Table. Module(Data. Set ds, String table. Name) { table = ds. Tables[table. Name]; } Spring 2009 Computer Science Department, TUC-N

Contract. Module subclass Contract. Module. . . public Contract. Module (Data. Set ds) :

Contract. Module subclass Contract. Module. . . public Contract. Module (Data. Set ds) : base (ds, "Contracts") {} public Data. Row this [long key] { get { String filter = String. Format("ID = {0}", key); return table. Select(filter)[0]; } } contract = new Contract. Module(dataset); Spring 2009 Computer Science Department, TUC-N

Revenue. Recognition class Revenue. Recognition. . . public Decimal Recognized. Revenue (long contract. ID,

Revenue. Recognition class Revenue. Recognition. . . public Decimal Recognized. Revenue (long contract. ID, Date. Time as. Of) { String filter = String. Format("Contract. ID = {0} AND date <= #{1: d}#", contract. ID, as. Of); Data. Row[] rows = table. Select(filter); Decimal result = 0; foreach (Data. Row row in rows) { result += (Decimal)row["amount"]; } return result; } Spring 2009 Computer Science Department, TUC-N

Which one to use? Spring 2009 Computer Science Department, TUC-N

Which one to use? Spring 2009 Computer Science Department, TUC-N

Active Record Fowler: An object that wraps a record data structure in an external

Active Record Fowler: An object that wraps a record data structure in an external resource, such as a row in a database table, and adds some domain logic to that object. An AR object carries both data and behaviour. The essence of an AR is a Domain Model in which the classes match very closely the record structure of the underlying database. Spring 2009 Computer Science Department, TUC-N

Class operations • construct an instance of the Active Record from a SQL result

Class operations • construct an instance of the Active Record from a SQL result set row • construct a new instance for later insertion into the table • static finder methods to wrap commonly used SQL queries and return Active Record objects • methods to update the database and insert into the database with the data in the Active Record • getting and setting methods for the fields • methods that implement some pieces of business logic Spring 2009 Computer Science Department, TUC-N

Implementation class Person. . . private String last. Name; private String first. Name; private

Implementation class Person. . . private String last. Name; private String first. Name; private int number. Of. Dependents; create table people (ID int primary key, lastname varchar, firstname varchar, number_of_dependents int) Spring 2009 Computer Science Department, TUC-N

Find + Load an object class Person. . . private final static String find.

Find + Load an object class Person. . . private final static String find. Statement. String = "SELECT id, lastname, firstname, number_of_dependents" + " FROM people" + " WHERE id = ? "; public static Person find(Long id) { Person result = (Person) Registry. get. Person(id); if (result != null) return result; Prepared. Statement find. Statement = null; Result. Set rs = null; try { find. Statement = DB. prepare(find. Statement. String); find. Statement. set. Long(1, id. long. Value()); rs = find. Statement. execute. Query(); rs. next(); result = load(rs); return result; } catch (SQLException e) { throw new Application. Exception(e); } finally { DB. clean. Up(find. Statement, rs); } } Spring 2009 Computer Science Department, TUC-N

public static Person load(Result. Set rs) throws SQLException { Long id = new Long(rs.

public static Person load(Result. Set rs) throws SQLException { Long id = new Long(rs. get. Long(1)); Person result = (Person) Registry. get. Person(id); if (result != null) return result; String last. Name. Arg = rs. get. String(2); String first. Name. Arg = rs. get. String(3); int num. Dependents. Arg = rs. get. Int(4); result = new Person(id, last. Name. Arg, first. Name. Arg, num. Dependents. Arg); Registry. add. Person(result); return result; } Spring 2009 Computer Science Department, TUC-N