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), ...
Patterns of Enterprise Application Architecture CS446/ECE452/SE464
Majed Al-Shawa
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?
A1: Performance • scalability =
A1: Performance • scalability = change in performance / change in resources
A1: Performance • scalability = change in performance / change in resources • scalabilityshark = (tpsnew - tpsold) / number of processors added
• scalabilitywhale = (tpsnew - tpsold) / number of processors added
A1: Performance • scalability = change in performance / change in resources • scalabilityshark = (tpsnew - tpsold) / number of processors added = (90 tps - 60 tps) / 1 processor = 30 tps / processor • scalabilitywhale = (tpsnew - tpsold) / 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.
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.
A2: Simple Expense-Tracking System •
Domain Logic • Transaction Script •
•
•
Data Source • Table Data Gateway • •
•
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)
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)
A2: Simple Expense-Tracking System •
Domain Logic • Transaction Script •
•
•
Data Source • Table Data Gateway • •
•
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)
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)
A2: Simple Expense-Tracking System •
Domain Logic • Transaction Script •
•
•
Data Source • Table Data Gateway • •
•
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)
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)
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
Q3: More Sophisticated ExpenseTracking 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.
A3: More Sophisticated ExpenseTracking 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
A3: More Sophisticated ExpenseTracking 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
A3: More Sophisticated ExpenseTracking 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
A3: More Sophisticated ExpenseTracking System Expense
- amount: int - account: Account - timeBooked: Time - type: ExpenseType + insert + update + delete + getTaxDeductableAmount(): int
TaxStrategy
Tables: Account, Expense
+ getTaxDeductableAmount (expense: Expense): int
Finder
+ findExpensesForAccount(id: int): Account
ConcreteTaxStrategy1 + getTaxDeductableAmount (expense: Expense): int
ConcreteTaxStrategy2 + getTaxDeductableAmount (expense: Expense): int
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.
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
Q5: Lazy loading collections How would you avoid ripple loading when loading a collection of objects using the lazy load mechanism?
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.
Q6: Identity Field Discuss the problems associated with the different ways of getting a new key for the Identity Field objectrelational structural pattern.
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
•
•
A query (in a separate transaction) allows multiple ID values to be retrieved
•
Nonstandard
GUID • Readability • Large in size
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 •
(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)
