程序代写代做代考 concurrency JDBC algorithm database Software Construction & Design 1

Software Construction & Design 1

The University of Sydney Page 1

Software Design and

Construction 2

SOFT3202 / COMP9202

Enterprise Application

Architecture Design Patterns

School of Information Technologies

Dr. Basem Suleiman

The University of Sydney Page 2

COMMONWEALTH OF AUSTRALIA

WARNING

This material has been reproduced and communicated to
you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the
Act ).

The material in this communication may be subject
to copyright under the Act. Any further copying or
communication of this material by you may be the
subject of copyright protection under
the Act.

Do not remove this notice.

The University of Sydney Page 3

Agenda

– Enterprise Application Architecture

– Layered Architecture

– Enterprise Application Design Patterns

– Unit of work

– Lazy load

– Value Object

The University of Sydney Page 4

Enterprise Applications

Architecture

The University of Sydney Page 5

Catalogue of Design Patterns

Design Pattern Description

Gang of Four (Gof) First and most used. Fundamental patterns OO development, but not

specifically for enterprise software development.

Enterprise Application

Architecture (EAA)

Layered application architecture with focus on domain logic, web,

database interaction and concurrency and distribution. Database

patterns (object-relational mapping issues)

Enterprise Integration Integrating enterprise applications using effective messaging models

Core J2EE EAA Focused on J2EE platform. Applicable to other platforms

Microsoft Enterprise

Solution

MS enterprise software patterns. Web, deployment and distributed

systems

https://martinfowler.com/articles/enterprisePatterns.html

The University of Sydney Page 7

Enterprise Applications

– Payroll, patient records, shipping tracking, insurance, accounting, insurance

– Involve lots of data

– Information systems or data processing

– Managing very large data using DBMS

– Data must be persistent (for many years even with SW/HW changes)

– Concurrent data access (web-based) require transaction management

– Data needs to be presented differently to end users

– Enterprise applications need to integrate with other applications

The University of Sydney Page 8

Enterprise Applications

– Enterprise applications need to integrate with other applications
– Developed using different technologies

– Data files, DBMS, communication among components

– Differences in business processes
– Complex business logic/rules

– Customer (one with current agreement or had a contract)

– Product sales vs service sales

– Different enterprise application types impose different design challenges

The University of Sydney Page 9

Enterprise Applications – Layered Architecture

– .

https://commons.wikimedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg#/media/File:Overview_of_a_three-

tier_application_vectorVersion.svg

The University of Sydney Page 10

Enterprise Applications – Principal Layers

Layer Description

Presentation Handle interactions between the user and the

application

Domain/Business

logic

Application logic including calculations based on

inputs, retrieving and storing data from the data

source

Data Source Storing persistence data. Works with other systems

such as transaction monitors and messaging system

The University of Sydney Page 11

Enterprise Applications – Layered Architecture

– .

The University of Sydney Page 12

Layering – Architectural Decision

– Performance is a significant design decision

– Response time: amount time it takes for the system to process a request

– Throughput: amount of work an application can handle in a given amount

of time

• Bytes per seconds, requests per second, transaction per second

– Other measures related to performance include responsiveness, latency,

scalability

The University of Sydney Page 13

Layering – Architectural Decision

– Many factors can influence performance while designing enterprise

applications

– Communication among different components

• Trips over the wire (networking)

• Communication styles (messaging, RPCs)

– System resources (memory, disk)

– Expensive system operations (database read/write)

– Sharing and concurrency

The University of Sydney Page 14

Mapping Objects to Database

– Data is modeled as objects in the domain model

but as tables (e.g., in RDB)

– Objects stored in-memory

– Tables stored persistently a database

– Issue: how to do mapping between in-memory

objects and database tables

The University of Sydney Page 15

What is a Transaction?

– Database technology allows application to define a transaction

– A segment of code that will be executed as a whole
– System infrastructure should prevent problems from failure and concurrency

– Transaction should be chosen to cover a complete, indivisible business

operation

– Book a seat

– Transfer money

– Withdraw cash

– Sell something

– Borrow a book

The University of Sydney Page 16

Transaction – ACID

– The transaction support should pass the ACID test
– Atomic (all, or nothing)

• Either transaction commits (all changes are made) or else it aborts (no changes

are made)

• Abort may be application-requested rollback, or it may be system initiated

– Consistent

– Isolated (no problems from concurrency; details are complicated)

• DBMS provides choices of “isolation level”

– Usually good performance under load is only available with lower isolation

– But lower isolation level does not prevent all interleaving problems

– Durable (changes made by committed transactions are not lost in failures)

The University of Sydney Page 17

Unit of Work

Object Relational Behavioural Pattern

The University of Sydney Page 18

Unit of Work Pattern

“Maintains a list of objects affected by a business transaction

and coordinates the writing out of changes and the resolution

of concurrency problems”

The University of Sydney Page 19

Unit of Work – Applicability

– Want to keep track of everything during a business transaction that can

affect the database

– Pulling data from a database

– Insert new objects you create and remove any objects you delete

– Might be useful with session objects

– Why not changing the database with each change to the object

model?

The University of Sydney Page 21

Unit of Work – Applicability

– Batch updates
– Multiple database updates as a unit

– One remote call rather than multiple

– JDBC allow such facility

– Any transactional resource not just databases

The University of Sydney Page 22

Unit of Work – How it Works

– Notify UoW of any change including:
– New object created

– Existing objects updated (modified/deleted)

– Existing objects being read (to ensure consistency)

– When a transaction has to be committed, UoW:
– Open a transaction

– Check concurrency (pessimistic/optimistic offline lock)

• Why not programmers make explicit database updates?

– Write changes out to the database

– Needs to know objects it should keep track of
– By caller or through the object itself

The University of Sydney Page 23

UoW – Caller Registration

– UoW needs to know what

objects it should keep track

– This can be realized by

Caller Registration

The University of Sydney Page 24

UoW – Object Registration

– UoW needs to know what

objects it should keep track

– This can be realized by

Object Registration

The University of Sydney Page 25

UoW – as Controller

– .

The University of Sydney Page 26

Unit of Work – Consequences

– Keep all information in one place

– Reduce number of database calls

– Handle business operation that span several transactions

– Alternatives can be impractical or difficult to manage
– Save any object whenever is changed

– Use variables to track objects that change

– Setting and finding objects through a special flag (dirty flag)

The University of Sydney Page 27

Lazy Load

Object Relational Behavioural Pattern

The University of Sydney Page 28

Lazy Load

“An object that doesn’t contain all of the data you need but

knows how to get it.”

The University of Sydney Page 29

Lazy Load – Applicability

– Depends on how much data need to retrieve from the database and how

many calls required to achieve that

– When the field requires extra database call(s)

– When you need to retrieve everything in one call, especially if it

corresponds to a single interaction

– Not useful when a field is stored in the same row as the rest of the object

The University of Sydney Page 30

Lazy Load – How it Works

– Four ways to implement Lazy Load:

– Lazy initialization

– Virtual Proxy

– Value Holder

– Ghost

The University of Sydney Page 31

Lazy Load – Lazy Initialization

– Use “null” to indicate That a field has not been loaded
– Every access to the field requires a “is-null” check

– A field with null means the value will need to be calculated before returning

the field

– The field should be self-encapsulated
– Access through getting method

– Use another check in case null is a legal field value

The University of Sydney Page 32

Lazy Initialization – Implementation

– Access of the products field for the first time cases the data to be loaded

from the database

The University of Sydney Page 33

Lazy Load – Virtual Proxy

– Object that looks like the object that should be in the field but it doesn’t

contain anything

– Virtual Proxy looks like exactly the same object suppose to be there

– Object identities issue
– Multiple virtual proxies (with different identities) for the same real object

– Dealing with many virtual proxies in statically-typed languages

The University of Sydney Page 34

Virtual Proxy – Implementation (1)

– List of products for a supplier to be held with a regular list field

– List proxy setup to provide the list that has to be created when it’s accessed

The University of Sydney Page 35

Virtual Proxy – Implementation (2)

– Virtual list instantiation with a loader that calls the appropriate loader

The University of Sydney Page 36

Virtual Proxy – Implementation (3)

– Product loader assignment to the list field

The University of Sydney Page 37

Virtual Proxy – Implementation (4)

– Evaluate the loader on the first reference

The University of Sydney Page 38

Virtual Proxy – Implementation (5)

– Regular list methods

The University of Sydney Page 39

Lazy Load – Value Holder

– An object that wraps some other object

– To get the underlying object, ask the value holder for its value on the first

access

– Lose explicit strong typing
– Class needs to know that it is present

– To avoid identity problems, ensure that the value holder is never passed out

beyond its owning class

The University of Sydney Page 40

Lazy Load – Ghost

– A real object in a partial state

– An object where every field is lazy-initialized in one go

– When an object is loaded from the database it contains just its ID. It’s full

state is loaded whenever an access to its filed is attempted

The University of Sydney Page 41

Lazy Load – Consequences (1)

– Virtual proxy/ghost can hold some data
– Data quick to retrieve and commonly used

– Issues with inheritance (in statically typed languages)
– Can’t decide the type of ghost/virtual proxy to create until the object is

loaded properly

– Lazy load may lead to database access more than needed
– Collection with lazy loads and read them one at a time (ripple loading)

– Make the collection itself as a lazy load and load all the contents

– That doesn’t scale with very large collections

The University of Sydney Page 42

Lazy Load – Consequences (2)

– Dealing with different degrees of laziness (which subset of the object fields is

needed)

– Use separate database interaction objects (one for each common scenario)

– E.g., two order mapper objects; one that loads line items immediately and one

loads it lazily

– More varieties of laziness, complexity overweight benefits

– Practically two: complete load and just enough load for identification

The University of Sydney Page 43

Value Object

Object Behavioural

The University of Sydney Page 44

Value Object

– What is the difference between value object and reference objects? Give

examples

The University of Sydney Page 47

Value Object

– “A small simple object whose equality isn’t based on identity”

– Applicability

– When you want to use equality on something other than identity

The University of Sydney Page 48

Value Object Example – Money

– Money represents a monetary value

– Many issues such as

– Multiple currencies: e.g., cannot add dollars to yen

– Rounding errors: losing cents/pennies

The University of Sydney Page 49

Value Object – Example

– Fields should be defined appropriately
– The amount as integral or a fixed decimal type – a float

type might introduce rounding problems
– Monetary values either rounded to the smallest complete unit or with

fractional units

– Arithmetic operations should be currency-aware
– Addition and subtraction

– Rounding issues in division and multiplication

– E.g., to add %5 tax, multiply it by 0.05

The University of Sydney Page 50

Value Object Example – Money

– Business rule: allocate the whole amount of a sum

of money to 2 accounts:
– 70% to Acc1 and

– 30% to Acc2

– How would an application allocate 5 cents?

The University of Sydney Page 51

Value Object Example – Money

– Allocator function
– Take ratio parameter as a list of numbers

– Returns list of monies without dropping scents

– A rule to enforce how to deal with allocation

The University of Sydney Page 52

Value Object Example – Money

– Currency conversion
– Simple solution Multiply by exchange rate

– But there might be some rounding issues – conversion rules may have

specific rounding

– Instead use converter object to encapsulate the conversion algorithm

– Money comparison
– Compare different currencies require currency conversion

The University of Sydney Page 53

Value Object Example – Money

– How to storing money in a database?
– As embedded value; currency for every money?

– Store the currency on the account and pull it whenever you load entries

– How to display money on a UI?
– Use printing behavior to display the correct amount with appropriate

currency

The University of Sydney Page 54