Data Access Objects?
rincewind
J2EE, and noticed some rather odd-looking technique being advertised as
a Good Thing. Namely, some people think that if you have a table, say,
Employees, then you should have some class called Employee, and you
should manipulate employees from you Java (VB, C++, whatever) code using
this Employee class, not Employees table directly, and that you should
use some kind of "presistence layer" that maps database to you Java objects.
I've always thought that data-only objects is a Bad Thing. Indeed, what
all these "Data Access Objects" are needed for - looks like they do
nothing but waste the memory?
H. S. Lahman
> I've been reading lately some introductory articles and tutorials on
> J2EE, and noticed some rather odd-looking technique being advertised as
> a Good Thing. Namely, some people think that if you have a table, say,
> Employees, then you should have some class called Employee, and you
> should manipulate employees from you Java (VB, C++, whatever) code using
> this Employee class, not Employees table directly, and that you should
> use some kind of "presistence layer" that maps database to you Java
> objects.
J2EE is a <somewhat> OO layered model infrastructure that is mainly
intended to support CRUD/USER processing. It seeks to decouple the
database view from the UI and other views. In doing so, the J2EE
infrastructure can provide a lot of the grunt work behind the scenes in
the infrastructure -- provided there is convenient 1:1 mapping between
objects in the application and tables in the DB. In effect it is just
defining a conversion between the OO view and the RDB view and it buries
the necessary encode/decode between those views in the infrastructure.
> I've always thought that data-only objects is a Bad Thing. Indeed, what
> all these "Data Access Objects" are needed for - looks like they do
> nothing but waste the memory?
There is nothing wrong with either data-only or behavior-only objects.
In fact, data holder objects are very important to using invariants and
parametric polymorphism. (There is a category on my blog that deals
with this.) Objects abstract problem space entities in terms of
knowledge and behavior responsibilities. If the underlying entity only
has knowledge, then so be it. For example, an object representing a
message data packet probably doesn't have a lot of intrinsic behaviors.
So...
Note that DAO objects are actually just message data packets for
communicating across the interface between the "business" layer and the
persistence layer. One encodes the values based on solution activities
and then essentially sends a message to the other layer with the data
packet.
DAOs serve a very important function by decoupling the implementations
of the layers. When a message is passed between layers the sender and
receiver need have no knowledge at all of how the other layer is
implemented. All they need to understand is the message identifier
(usually a method name in the layer interface) and the layout of the
data values in the data packet. Each side gets to map the data packet
from its own semantic perspective. The DAO essentially defines that
layout of the message data packet and that definition is all that the
two layers share.
--
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
frebe
tables is an old technique, still used, and probably to be used in the
future too. It does not matter where you look, COBOL, VB, C++, PL/SQL
or Java. The concept is used everywhere. It is just a convenient of
carrying around the data in applications.
First, the name "persistence layer" is a little bit wrong. It gives you
the impression that it only handles writing and reading to/from disk. I
think that the correct name would be "database layer". Anyway the
purpose with "persistence layers" like Hibernate, EJB or JDO is to
avoid putting SQL strings in your code. Using embedded SQL would indeed
mostly solve this problem, but by some (to me unknown) reason, the
usage of emedded SQL has been abandoned.
In case of EJB and JDO the purpose is also to make your application
independent of database paradigms (relational, hierachial, network or
direct file access). The cost of this is very high, because only a
subset of the features in a RDBMS can be used, and the usage of
non-relational databases is extremly low.
The name of classes carrying record data is not "Data Access Objects"
(DAO). A DAO is a functional object with no state performing SQL
operations. The name of the objects you are talking about is "Value
Objects" (VO). DAO objects are used when you make a custom "persistence
layer", in opposite to Hibernate, EJB, JDO, etc, and need portablity
between database paradigms. For example, if you want your application
to work with both a relational database and using direct file access,
you can have a DAO interface with two implementations for each
scenario. If you don't need this kind of portability the DAO concept is
just a huge waste of development time.
Using VO does not have to be waste of memory. You only wast memory if
you immediately creates VO for every row in a query result. The correct
way is to loop the query result and create a corresponding VO for every
iteration. The previos VO should be thrown away. The problem is that I
am not sure in what extent the mainstream "persistence layers" support
this technique.
Fredrik Bertilsson
http://butler.sourceforge.net
Robert C. Martin
There is a school of thought that says that software applications
should not be coupled to the form of the data in a database. The fact
that databases tend to store data in tables is a detail that the
application should not know about. Instead, the application should
assume that all the data it needs is in a form that is most convenient
for it's purposes (usually objects in RAM).
This decoupling allows the application to use any form of persistence,
including databases, flat files, flash memory, or even persistent RAM.
A persistence layer is the layer that transforms the form of the data
from that which is convenient for the DBMS, to that which is
convenient for the application.
Data Access Objects (DAOs) are intermediate forms. They are simple
data structures that have little or no business behavior and who's
purpose is to participate in the translation from one form to another.
One might have DAOs that look similar to relational tables, and other
DAOs that look similar to the application objects.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
Ilja Preuß
I think you are mixing up DAOs and DTOs here - Data Transfer Objects are the
data packets, Data Access Objects contain the database (or whatever) logic.
Regards, Ilja
Robert C. Martin
(Sorry, I meant Data Transfer Objects, as did the OP)
H. S. Lahman
> I think you are mixing up DAOs and DTOs here - Data Transfer Objects are the
> data packets, Data Access Objects contain the database (or whatever) logic.
Doesn't that depend on which layer one is standing in? That is, the DTO
has the data to transfer to the Data layer from the Business layer and
the DAO has the data to transfer to the Database layer from the Data
layer(?). (It has been many, many moons since I've looked at the
CRUD/USER layered models, so I might well have screwed it up.)
Ilja Preuß
> Responding to Preuß...
>
>> I think you are mixing up DAOs and DTOs here - Data Transfer Objects
>> are the data packets, Data Access Objects contain the database (or
>> whatever) logic.
>
> Doesn't that depend on which layer one is standing in? That is, the
> DTO has the data to transfer to the Data layer from the Business
> layer and the DAO has the data to transfer to the Database layer from
> the Data layer(?). (It has been many, many moons since I've looked
> at the CRUD/USER layered models, so I might well have screwed it up.)
As far as I know, the DTO is a simple data holder - only fields, and perhaps
getters, no behaviour. A DAO, in contrast, contains the logic to extract the
requested data from the data storage.
Cheers, Ilja
H. S. Lahman
OK, I think I see the disconnect (though it is possible I am missing
something more fundamental). In my world DAO's "behavior" is just a
smart setter. It just initializes only its own knowledge attributes
and, in doing so, applies no business rules or policies that are unique
to the problem in hand. IOW, all it is doing is forming a message
(e.g., a SQL query) to request its data.
An analogy would be a Matrix object that has complex algorithmic
operations like "transform" and "invert" that affect lots of its data
elements. But those operations are defined by a scope (mathematics)
well beyond the problem in hand and they are self-contained. So in the
problem context the Matrix is still just a dumb data holder and the
methods, however complex their manipulations may be, are just setters
for its knowledge responsibilities rather than unique behavior
responsibilities.
[The distinction between knowledge and behavior tends to be more
important to translationists because the code generator needs to
unambiguously deal with scope for synchronous knowledge access if it
implements concurrently. Life is much simpler if that is at the
getter/setter method boundary. B-) (Technically the translation
methodologies refer to knowledge accessors as "synchronous services"
because the assumption is knowledge is accessed synchronously on an
as-needed basis while they put all the functional behavior into actions
in object state machines, whose access is inherently asynchronous.)]
CodeFutures
Data Access Objects and Data Transfer Object are a Core J2EE Design
Patterns
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://www.codefutures.com/data-access-object/
That means that they are 'best practices' - and that many Java
developers in many organizations are using them. Even if you don't see
a benefit in your particular project, there are major benefits on
standardizing your architecture. It certainly reduces long term
maintenance costs.
The choice of Java persistence technology (EJB CMP, JDBC, JDO,
Hibernate, etc)to use with your Data Access Objects is another
question, of course. And using Data Access Objects means you can
change the underlying persistence technology without changing other
parts of the application.
PJ Murray
CodeFutures Software
Java Code Generator for Data Persistence