Patterns of Enterprise Application Architecture

Transcription

1 Patterns of Enterprise Application Architecture CS446/ECE452/SE464 Majed Al-Shawa

2 Q1: Performance There are two systems, Shark and Whale. Each system is running on a single processor, but Shark produces 60 tps (transactions per second), while Whale produces 40 tps. After adding a processor to each system, Shark produces 90 tps and Whale produces 80 tps. As more processors are added, each system exhibits a linear increase in performance. Which system is more scalable, with respect to processor addition?

3 A1: Performance scalability =

4 A1: Performance scalability = change in performance / change in resources

5 A1: Performance scalability = change in performance / change in resources scalability shark = (tps new - tps old ) / number of processors added scalability whale = (tps new - tps old ) / number of processors added

6 A1: Performance scalability = change in performance / change in resources scalability shark = (tps new - tps old ) / number of processors added = (90 tps - 60 tps) / 1 processor = 30 tps / processor scalability whale = (tps new - tps old ) / number of processors added = (80 tps - 40 tps) / 1 processor = 40 tps / processor

7 A1: Performance scalability = change in performance / change in resources scalability shark = (tps new - tps old ) / number of processors added = (90 tps - 60 tps) / 1 processor = 30 tps / processor scalability whale = (tps new - tps old ) / number of processors added = (80 tps - 40 tps) / 1 processor = 40 tps / processor Therefore, Whale is a more scalable system Obviously, this calculation works only because the example assumes linear growth in performance. In general, you have to compare the two [performance vs. resource] curves for a range of resources.

8 Q2: Simple Expense-Tracking System There is a simple expense-tracking system that keeps track of expenses incurred on accounts for a small company. An expense is simply some amount of money that is incurred on an account at a point in time for some purpose. The system can perform three kinds of operations: 1) book an expense for an account 2) determine the expense balance for an account for a range of dates 3) determine the largest expense in the system What domain logic and data source architectural patterns would you use? Describe each pattern and explain why you would use each pattern. Show the class diagrams and the database schema used.

9 A2: Simple Expense-Tracking System Domain Logic Transaction Script Description: 1 business logic-containing procedure for each presentation request Reason for usage: simple implementation that works for a simple problem (few rules, not complex) Data Source Table Data Gateway Description: 1 class provides interface to perform database access on 1 table Reason for usage: separate queries from business logic, granularity appropriate for this small problem (even just one Table Data Gateway for all tables) Database schema CREATE TABLE accounts (ID int primary key, description varchar) CREATE TABLE expenses (ID int primary key, accountid int foreign key references accounts(id), amount int, description varchar, timebooked datetime)

10 A2: Simple Expense-Tracking System Domain Logic Transaction Script Description: 1 business logic-containing procedure for each presentation request Reason for usage: simple implementation that works for a simple problem (few rules, not complex) Data Source Table Data Gateway Description: 1 class provides interface to perform database access on 1 table Reason for usage: separate queries from business logic, granularity appropriate for this small problem (even just one Table Data Gateway for all tables) Database schema CREATE TABLE accounts (ID int primary key, description varchar) CREATE TABLE expenses (ID int primary key, accountid int foreign key references accounts(id), amount int, description varchar, timebooked datetime)

11 A2: Simple Expense-Tracking System Domain Logic Transaction Script Description: 1 business logic-containing procedure for each presentation request Reason for usage: simple implementation that works for a simple problem (few rules, not complex) Data Source Table Data Gateway Description: 1 class provides interface to perform database access on 1 table Reason for usage: separate queries from business logic, granularity appropriate for this small problem (even just one Table Data Gateway for all tables) Database schema CREATE TABLE accounts (ID int primary key, description varchar) CREATE TABLE expenses (ID int primary key, accountid int foreign key references accounts(id), amount int, description varchar, timebooked datetime)

12 A2: Simple Expense-Tracking System Class diagrams Services group the Transaction Scripts in meaningful ways As data complexity increases, multiple Table Data Gateways may be used AccountService + bookexpense(expense: ExpenseBean): void + getexpensesbalance (accountid: int, starting: Time, ending: Time): Money <<accesses DB usings>> Gateway + insertexpense(accountid: int, amount: int, description: String, timebooked: Time): void <<provides access to>> <<Database>> ExpenseService + getlargestexpense(): ExpenseBean <<accesses DB usings>> + findexpenses(accountid: int, starting: Time, ending: Time): ResultSet + remove + update

13 Q3: More Sophisticated Expense- Tracking System There is an expense-tracking system that has a slightly more sophisticated business logic than the previous system, for which you re able to create your own database schema. This system can perform numerous tax-related operations on expenses, including the ability to determine how much of an expense is tax-deductible according to different tax laws Your team is comfortable with object-oriented design. What domain logic and data source architectural patterns would you use? Describe each pattern and explain why you would use each pattern. Show the class diagrams.

14 A3: More Sophisticated Expense- Tracking System Domain Logic Simple Domain Model Description: an object model of the domain incorporates both behaviour and data, but that is not very complicated Reason for usage: complex business logic Data Source Active Record Description: an object that wraps a row in a database table or view, encapsulates the database access and adds domain logic on that data Reason for usage: Simple Domain Model, class structure not very different from the database schema

15 A3: More Sophisticated Expense- Tracking System Domain Logic Simple Domain Model Description: an object model of the domain incorporates both behaviour and data, but that is not very complicated Reason for usage: complex business logic Data Source Active Record Description: an object that wraps a row in a database table or view, encapsulates the database access and adds domain logic on that data Reason for usage: Simple Domain Model, class structure not very different from the database schema

16 A3: More Sophisticated Expense- Tracking System Domain Logic Simple Domain Model Description: an object model of the domain incorporates both behaviour and data, but that is not very complicated Reason for usage: complex business logic Data Source Active Record Description: an object that wraps a row in a database table or view, encapsulates the database access and adds domain logic on that data Reason for usage: Simple Domain Model, class structure not very different from the database schema

17 A3: More Sophisticated Expense- Tracking System - description: String - type: AccountType + insert + update + delete Account <<Database>> Tables: Account, Expense <<provides access to>> <<provides access to>> <<provides access to>> - expenses 1 0..* Expense - amount: int - account: Account - timebooked: Time - type: ExpenseType + insert + update + delete + gettaxdeductableamount(): int TaxStrategy + gettaxdeductableamount (expense: Expense): int <<calculates tax deductable amount using>> Finder ConcreteTaxStrategy1 ConcreteTaxStrategy2 + findexpensesforaccount(id: int): Account + gettaxdeductableamount (expense: Expense): int + gettaxdeductableamount (expense: Expense): int

18 Q4: Lazy loading using ghosts What design mechanisms are used to decouple domain objects in the domain logic layer from data mappers in data source layer when loading ghosts? Explain the rationale behind the mechanisms.

19 A4: Lazy loading using ghosts DomainObject needs to access DataSource, however, DomainObject should not be dependent on DataSource Therefore we use dependency inversion, which means that DomainObject accesses DataSource interface (IDataSource), which is in the domain logic layer There is a subclass of Mapper for every subclass of DomainObject MapperRegistry receives operations against an instance of a subclass of DomainObject, looks up the corresponding singleton subclass of Mapper, then forwards operations to the singleton MapperRegistry is a middleman that allows decoupling of concrete Mappers from concrete DomainObjects MapperRegistry, in the data source layer, implements the DataSource interface

20 Q5: Lazy loading collections How would you avoid ripple loading when loading a collection of objects using the lazy load mechanism?

21 A5: Lazy loading collections Lazy Loading the Collection The collection is Lazy Loaded. The database is hit once for the entire collection and all of its objects are retrieved at once.

22 Q6: Identity Field Discuss the problems associated with the different ways of getting a new key for the Identity Field objectrelational structural pattern.

23 A6: Identity Field Auto-generate Auto-generated field Can determine the new key only after insertion Cumbersome to insert rows related by foreign key constraints due to the need to specify foreign keys Database counter GUID A query (in a separate transaction) allows multiple ID values to be retrieved Nonstandard Readability Large in size

24 A6: Identity Field Generate your own Table scan using SQL max function (largest integer in the column + 1) Read-locks the table, preventing concurrent updates/insertions (resource contention) Must ensure complete isolation between transactions (otherwise, duplicate IDs) Separate key table <table name, latest key value> (database wide key system means 1 row only, with table name =database name) Key table update should be in a separate transaction. Otherwise, other transactions requiring access to the same row cannot continue. But putting into a separate transaction means that rollback of transactions will cause the new keys made by these transactions to become invalid (but this can be fixed)