Data Source Architectural

Patterns

Krishnaprasad P.K

Slide 1
 Syllabus – Module IV
• Defining EAI, Data-Level EAI, Application Interface-Level EAI.,
Method- Level EAI., User Interface-Level EAI, The EAI Process -
An Introduction to EAI and Middleware, Transactional Middleware
and EAI, RPCs, Messaging, and EAI, Distributed Objects and EAI,
Database- Oriented Middleware and EAI, Java Middleware and EAI,
Implementing and Integrating Packaged Applications—The General
Idea, XML and EAI, Message Brokers—The Preferred EAI Engine,
Process Automation and EAI. Layering, Organizing Domain Logic,
Mapping to Relational Databases, Web Presentation, Domain Logic
Patterns, Data Source Architectural Patterns, Object-Relational
Behavioral Patterns, Object-Relational Structural Patterns, Object-
Relational Metadata Mapping Patterns, Web Presentation Patterns,
Slide 2
Distribution Patterns, Offline Concurrency Patterns.
 Data Source Architectural Patterns

1. Table Data Gateway

2. Row Data Gateway

3. Active Record

4. Data Mapper

Slide 3
 Gateway
– Gateway: “An object that encapsulates access to an external system
or resource”.
– Object-oriented system often has to deal with things that aren't
objects, such as relational database tables
– Wrap all the special API code of external resources like DB into a
class whose interface looks like a regular object.
– Other objects access the resource through this Gateway, which
translates the simple method calls into the appropriate specialized
API.
– Gateway is helpful if we are changing the external resources.

Slide 4
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Table Data Gateway
– Two main ways (w.r.t Datasource) in which you can use a Gateway

1. Table Data Gateway: “An object that acts as a Gateway to a

database table. One instance handles all the rows in the table.”
2. Row Data Gateway: “An object that acts as a Gateway to a single
record in a data source. There is one instance per row”

– A Table Data Gateway(TDG) holds all the SQL for accessing a single
table: selects, inserts, updates, and deletes.
– Other code calls TDG’s methods for all interaction with the
database.

Slide 5
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Table Data Gateway: How it works
– It usually consisting of several find methods to get data from the
database and update, insert, and delete methods.

– Each method maps the input parameters into a SQL call and executes
the SQL against a database connection.

– The Table Data Gateway is usually stateless, as its role is to push

data back and forth.

– How it returns information from a query. E.g: Record Set.

» (Record Set: An in-memory representation of tabular data.)

– One gateway for each table.

Slide 6
 Table Data Gateway
– Table Data Gateway is probably the simplest database interface
pattern to use.
– It provides good decoupling.
– Good choice for Table Module .
– Approach widely used in .NET
– Table Data Gateway is also suitable for Transaction Scripts.

– One of the benefits of using a Table Data Gateway to encapsulate

database access is that
» The same interface can work both for using SQL to manipulate the
database and for using stored procedures.

– Stored procedures themselves are often organized as Table Data

Gateways.

Slide 7
 Row Data Gateway
– Row Data Gateway: “An object that acts as a Gateway to a single
record in a data source. There is one instance per row”

– Embedding database access code in in-memory objects have a few

disadvantages
– Adding the database manipulation code to the in-memory objects who
have business logic of their own, increases complexity.
– If your in-memory objects are tied to a database, tests are slower to
run because of all the database access.

– A Row Data Gateway provides objects that look

exactly like the record,
but can be accessed with the regular mechanisms
of any programming language.
– All details of data source access are hidden
behind this interface.
Slide 8
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Row Data Gateway: How it works
– A Row Data Gateway acts as an object that exactly mimics a single
record.

– Each table column is a field in the object.

– The Row Data Gateway will usually do any type conversion from the
data source types to the in-memory types.

– The gateway acts as a good interface for each row of data.

– A Row Data Gateway should contain ONLY database access logic and
NO domain logic.

– It often makes sense to have separate finder objects so that each

table in a relational database will have one finder class and one
gateway class for the results.

Slide 9
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Row Data Gateway:

– Row Data Gateways tend to be somewhat tedious to write, but

they're a very good candidate for code generation based on a
Metadata Mapping.

– This approach works particularly well for Transaction Scripts.

Slide 10
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Active Record
– “An object that wraps a row in a database table, encapsulates the
database access, and adds domain logic on that data.”
– An object carries both data and behaviour.
– Active Record uses the most obvious approach, putting data access
logic in the domain object. This way all people know how to read and
write their data to and from the database.

Slide 11
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Active Record: How it works

– The essence of an Active Record is a Domain Model in which the

classes match very closely the record structure of an underlying
database.

– Each Active Record is responsible for saving and loading to the

database and also for any domain logic that acts on the data.

– The data structure of the Active Record should exactly match that
of the database. (one field in the class for each column in the table)

– In this pattern the classes are convenient, but they don't hide the
fact that a relational database is present.

– The principal difference is that a Row Data Gateway contains only

database access while an Active Record contains both data source
and domain logic.
Slide 12
 Active Record: How it works

– The Active Record class typically has methods that do the following:

– Construct an instance of the Active Record from a SQL result

set row

– Construct a new instance for later insertion into the table.

– Finder methods to wrap commonly used SQL queries and return

Active Record objects.

– Update the database and insert into it the data in the Active
Record.

– Get and set the fields. (convert from SQL-oriented types to better
in-memory types.)

– Implement some pieces of business logic.

Slide 13
 Active Record: When to Use It

– Fit to Domain Model and not to complex data.

– Derivations and validations based on a single record work well in this

structure.

– It's easy to build Active Records, and they are easy to understand.

– Primary problem is that they work well only if the Active Record
objects correspond directly to the database tables: an isomorphic
schema.

– If your business logic is complex, the above mapping will be difficult

to achieve, we have to use Data Mapper instead.

– Due to this isomorphic schema between object and DB, it is more

difficult to refactor either design as a project goes forward.
Slide 14
 Data Mapper

– Mapper: “An object that sets sup a communication between two

independent objects”.
– “A layer of Mappers that moves data between objects and a database
while keeping them independent of each other and the mapper itself”.

– Many parts of an object, like inheritance, aren't present in relational

databases.
– The object schema and the relational schema don't match up.

Slide 15
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Data Mapper

– The Data Mapper is a layer of software that separates the in-

memory objects from the database

– Its responsibility is to transfer data between the two and also to

isolate them from each other

– With Data Mapper the in-memory objects needn't know even that
there's a database present; they need no SQL interface code, and
certainly no knowledge of the database schema.

Slide 16
 Data Mapper: How It Works
– The separation between domain and data source is the main function
of a Data Mapper.
– Mapper uses Identity Map to see if object is already loaded. If not it
loads it.
– Identity Map: “Ensures that each object gets loaded only once by
keeping every loaded object in a map“
Retrieving data from a database.

Slide 17
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”
 Data Mapper: How It Works

– The whole layer of Data Mapper can be substituted, to allow a single

domain layer to work with different databases.

– Simple Data Mappers map in-memory object to table on a field-to-

field basis.

– Others need to map more complicated object hierarchies to multiple

tables.

– For insert and updates: The mapper must know what objects have
changed, which are new, and which must be destroyed.

Slide 18
 Data Mapper: When to Use It

– Database and object model must be independent.

– Data Mappers are useful with Domain Model.

– For simple Domain Model an Active Record could be used, but as it

becomes more complicated some mapping is needed.

Slide 19
 Reference
[1] Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee,
Randy Stafford, “Patterns of Enterprise Application Architecture”,
Addison- Wesley, 2002.

Slide 20
Source: Martin Fowler, “Patterns of Enterprise Application Architecture”