Transcript Data Access Patterns

Data Access Patterns
Motivation
• Most software systems
require persistent data (i.e.
data that persists between
program executions).
• In general, distributing
low-level data access logic
throughout a program is
not a good idea (design).
Program
select * from Items
rs.getString("Name")
Data
Data Access Layer
• A better design is one that includes a data access
layer which encapsulates the details of the
underlying persistence API.
• It abstracts the low-level details of persistent
storage.
• It provides an interface that is usually a better
match for the style of programming used in the
domain logic. For example, the data access layer
might provide an OO interface onto relational
data.
Program
Program
customer = dao.find(id)
update(customer)
select * from Items
rs.getString("Name")
Data Access Layer
select * from Items
rs.getString("Name")
Data
Data
Program to an Interface; Not
Implementation
SQL
• Most software systems that need persistent storage more
powerful than a flat file end up using a relational database
management system
• SQL is the standard language for managing data in a
relational database.
• Mixing SQL with application logic is considered poor
design.
– Writing simple SQL statements takes a fair amount of skill, and
writing efficient SQL statements takes even more. If you mix SQL
and application logic, it makes it harder for those unskilled in SQL
to work with the code.
– Changes to the database may necessitate changes to the SQL that
accesses the database. If the SQL is spread throughout the
program, a small change to the database might cause a strong
ripple effect throughout the program.
General benefits of having a
data access layer
• Separation of concerns. Data storage logic
is kept separate from domain logic.
• Information hiding. Domain logic avoids
dependencies on database schema.
• Ability to change DB vendors without
disrupting client code.
Data Access Architecture
Patterns
• Key architecture patterns used in the
implementation of a data access layer:
– Table Data Gateway (aka Data Access Object)
– Row Data Gateway
– Active Record
Table Data Gateway
• Put all the logic for managing
the records of a table into one
class.
• There is one instance of the
class for each table/view.
• find() methods return data for one row of the table/view.
• insert(), update() and delete() modify one row.
• Stateless (unlike Row Data Gateway)
• A Data Transfer Object (DTO) may be used to
encapsulate and return record values.
• Customer in the class diagram to the right is an example of
a DTO.
Table Data Gateway Variations
• Customer might include
an id field. This would
simplify certain routines:
update(Customer)
• There may be find methods that return more than
one record. One option for implementing such
methods is to return a collection of DTO’s:
List<Customer> find(criteria)
Design Decisions/Discussion
• find() methods can return:
– Record set (data structure from SQL query such
as ResultSet). Convenient if find returns
multiple records.
– Data Transfer Object (object with getters and
setters used to pass data around)
– Generic collection class (e.g. map which may
contain instances of a DTO)
• If table/view is read only, there is no need
for insert, update and delete.
Row Data Gateway
• Define a stateful class
that encapsulates the
data for one record of
your data source.
• There is one instance
per row.
• The logic to find a record
(one instance of the row
data gateway class) can be
represented as static methods on the row data
gateway class or encapsulated in a separate finder
class.
Usage scenarios
• Use finder object to fetch one row (an
instance of row data gateway). Make
updates to instance (it’s stateful). Ask
instance to update().
• Create an instance of row data gateway.
Ask instance to insert().
When to use each pattern?
• Table Data Gateway is probably the simplest of all
three. It also works well when you want to (or it’s
not an inconvenience to) use record sets from SQL
query.
• Row Data Gateway is convenient when you need
data from two or more records in memory at once
and it’s inconvenient to store the data in another
data object (inconvenient = don’t want to create
another object).
• Row Data Gateway also factors out the find/access
logic. This is useful if it needs to be reused or can
vary.
Active Record
• Active Record is a
Row Data Gateway
class with domain
logic.
References
• Patterns of Enterprise Application Architecture
• Data Access Patterns: Database Interactions in
Object-Oriented Applications
• Pattern-Oriented Software Architecture: A
Pattern Language for Distributed Computing,
4th Volume
• Agile Principles, Patterns, and Practices in C#
• Core J2EE™ Patterns: Best Practices and
Design Strategies
Android
Persistent Storage in Android
• Options:
–
–
–
–
–
Shared Preferences
Internal Storage – local to application
External Storage – shared space
SQLLite Database
Network Resources
Shared Preferences
• PreferenceActivity – standard way of saving settings
• getSharedPreferences() –
– Example: SharedPreferences preferences =
getSharedPreferences(PREF_FILE_NAME, MODE_PRIVATE);
• getPreference - uses the getSharedPreferences() method
with the name of the activity class for the preference file
name
• getDefaultSharedPreferences – similar to getPreference()
but uses a default file name.
• Limited to boolean, float, long and String.
Internal Storage
•
•
•
•
openFileInput()
openFileOutput()
deleteFile()
fileList()