DAO patterns in the "Real World"

[Roger Varley]

Hi

I've recently been looking at the DAO pattern. All the tutorials I have
seen so far deal with small, simple databases that maintain students or
CD collections and always build java objects that contain all the
fields in the database and the update function always updates all the
fields in the database whether they need updating or not.

However, "in the real world" a database will contain a mixture of
fields some of which are user maintainable, some of which are intended
to be maintained by other parts of the application. In most cases
(other than creation of new entries in the database) you will be
dealing with sub-sets of the data (maybe overlapping data sets as well)
and, within those subsets, some fields will be meant for updating, some
will be for display purposes only ( for example, a customer name may be
included to assist the user when maintaing fields). Implementing the
DAO pattern as shown in the tutorials becomes unweildy.

For example, the customer in a SAP R/3 environment is implemented by a
single master table with > 150 fields and several associated tables
that hold repeating data and some of these hold several rows per
customer and contain > 100 fields per row. So creating a java
representation of the full customer in every case and updating every
field when an update is issued is clearly not the way to do things.

How do people approach the DAO pattern in these circumstance? I'm
currently leaning towards having multiple customer objects each looking
at the database fields required for each piece of functionality, but
this seems to be a very messy way of doing things.

Regards
Roger

 

[kjc]

Hi

I've recently been looking at the DAO pattern. All the tutorials I have
seen so far deal with small, simple databases that maintain students or
CD collections and always build java objects that contain all the
fields in the database and the update function always updates all the
fields in the database whether they need updating or not.

However, "in the real world" a database will contain a mixture of
fields some of which are user maintainable, some of which are intended
to be maintained by other parts of the application. In most cases
(other than creation of new entries in the database) you will be
dealing with sub-sets of the data (maybe overlapping data sets as well)
and, within those subsets, some fields will be meant for updating, some
will be for display purposes only ( for example, a customer name may be
included to assist the user when maintaing fields). Implementing the
DAO pattern as shown in the tutorials becomes unweildy.

For example, the customer in a SAP R/3 environment is implemented by a
single master table with > 150 fields and several associated tables
that hold repeating data and some of these hold several rows per
customer and contain > 100 fields per row. So creating a java
representation of the full customer in every case and updating every
field when an update is issued is clearly not the way to do things.

How do people approach the DAO pattern in these circumstance? I'm
currently leaning towards having multiple customer objects each looking
at the database fields required for each piece of functionality, but
this seems to be a very messy way of doing things.

Regards
Roger

Use Hibernate

 

[Roger Varley]

I'm not familiar with Hibernate. Is this going to save me creating and
moving around huge objects of which the majority of the attributes I'm
not interested in or will Hibernate just make it easier to
create/update these huge objects?

Regards
Roger

 

[hilz]

I'm not familiar with Hibernate. Is this going to save me creating and
moving around huge objects of which the majority of the attributes I'm
not interested in or will Hibernate just make it easier to
create/update these huge objects?

Regards
Roger

I am not sure what you mean by this question, but hibernate is a framework
for ORM.
I have just started learning it, and it seems to solve a lot of the problems
that you might face in a commercial grade application. It is very well
thought and documented. It is gaining a lot of support in the java
community, and i beleive it is the best way to go when it comes to java
object persistence.

check it out
http://www.hibernate.org/

thanks
hilz

 

[GregSmith]

The twin or dual to the DAO pattern is the DTO or Data Transfer Object.
You should look at it and the Composite Object as well. DTOs are used
to return an entire set of columns from a single row in a table. If
you have columns that refer to another table, you can go get them as
you need them. This is called Lazy Loading.

However, what I think you are saying is that you have more than just
plain tables that are your data objects, but also views. A view is a
collection of fields from different tables. In that case, you would
create a seperate DAO/DTO pair for each view. And that can get very
involved. I have seen projects with 10 tables, but 150 views - hence
150 DAO/DTO sets. Often, it is easier to just deal with 1 Table = 1 DAO
and access the views by loading up all the DTOs you need as you need
them.

IMHO, views are nasty and they are the main reason I dislike RDBMS.
DAOs and Hibernate are more applicable to an Object Oriented view of
data. And in this paradigm, usually one table equals one object.
You'll see this again in EJB as well. Hibernate allows you to map
tables to actual objects and avoid the DAO/DTO pattern and use Plain
Old Java Objects (POJOs). It is much easier.

Beware of Hibernate - for personal projects it works fine, but for
enterprise projects I would be concerened. Hibernate is a product, not
a specification. If for some reason the folks at Hibernate disappear,
then you are left with no support. JDO and EBJ 3.0 both have POJO
persistance specifications in the Java Community Process (hosted by Sun
Microsystems). They, however are not mature. The good news about
using a product based on a specification is that there are mutliple
vendors and you should (in theory) be able to swap vendor's solutions
at will.

 

[Roger Varley]

Greg

What I'm really trying to say is that, particularly when large table(s)
are involved - 99 times out of 100 you're simply not interested in the
majority of the attributes, you only want the subset of the data that
applies to the functionality that you're implementing. The DAO
tutorials are too simplistic and assume that every time you create the
java DAO you want all the attributes and everytime you update the DAO
all the fields get updated. In the example I gave regarding the SAP
R/3 environment this would mean that using your view of DAO - one table
one DAO would mean constructing (by hand or by framework) huge DAO/DTO
objects when the majority of the data is simply not required.

As an aside I was interested by your view that I should be mapping one
DAO/DTO pair per table. I was lead to believe that there should be just
one DAO that interacted with the underlying persistance layer so that
the application layer should see a DAO with all of the operations that
need to be performed to acheive the required functionality e.g
getCustomer() method, listInvoices() etc etc and the DAO layer returns
the DTO regardless of whether the data lies in one table or multiple
tables - or am I confused about the DAO pattern.

 

[Gerbrand van Dieijen]

Roger Varley schreef:

Greg

What I'm really trying to say is that, particularly when large table(s)
are involved - 99 times out of 100 you're simply not interested in the
majority of the attributes, you only want the subset of the data that
applies to the functionality that you're implementing.

With JDO, this depends on the implementation. I use JDOGenie, and
normally it will only retrieve the values when you need them. However,
you can specify via an XML file when values have to be retrieved all at
once when you now it's needed in advance.
I suspect this is similar for Hybernate.

Anyway, you can best let specialized frameworks like EJB or
JDO-implemntations or Hybernate do all to work, including
optimalizations as you mentions.
Best approach for developing is: first develop a readably, sound
implementation (like described in the tutorials), then *only* optimize
when needed.

I don't think you should be concerned wether your table has 5 or 1000
attributes. The tutorials still apply. It your application should become
slow, usually this is not because if these problems but from wrong
algorithms (for example a bubble sort in stead of merge of quick sort)
or wrong patterns.

Similar idea is, how to use a loop:
When I was less experienced in programming, I use to write
int myvalue=0;
for (int i=0;i<10;i++) {
myvalue=calculate(i);
}
however, now I write:
for (int i=0;i<10;i++) {
int myvalue=calculate(i);
}

This may seem less optimal, because myvalue seems to be declared in
every loop. However, a compiler automatically recognises this and
optimizes the code as was above. The advantage is a much smaller change
at bugs, which is much worse then sligthly less optimized.

(You may already now this, but I though about it when I wrote the reply)

 

[Michael Borgwardt]

I'm not familiar with Hibernate. Is this going to save me creating and
moving around huge objects of which the majority of the attributes I'm
not interested in

Yes, that's one of the things Hibernate can do. Basically, it lets you map
any Java object's properties to a database, including the representation
of 1:n and n:m relationships as Java collections. Regarding your question,
you can map any number of Java classes to the same table, using different
subsets of its fields. It's just like the different DAOs you mentioned,
only you don't have to program them yourself beyond specifying the
details of the mapping.

 

[Stephen Riehm]

Similar idea is, how to use a loop:
When I was less experienced in programming, I use to write
int myvalue=0;
for (int i=0;i<10;i++) {
myvalue=calculate(i);
}
however, now I write:
for (int i=0;i<10;i++) {
int myvalue=calculate(i);
}

don't those two loops have different semantics, ie: the scope of myvalue?
My understanding would be that myvalue in the first loop would be
overwritten 9 times and then the last value would be available to code
appearing after the loop. The myvalue in the second loop basically has
no effect because it falls out of scope (and into the garbage
collector's hands) as soon as you leave the loop.

or am I missing something?

Steve
(just getting to grips with java)

 

[xarax]

don't those two loops have different semantics, ie: the scope of myvalue?
My understanding would be that myvalue in the first loop would be
overwritten 9 times and then the last value would be available to code
appearing after the loop. The myvalue in the second loop basically has
no effect because it falls out of scope (and into the garbage
collector's hands) as soon as you leave the loop.

or am I missing something?

You're missing the fact that primitive values, like "int",
are not garbage collected.

Otherwise, the only difference is the visibility of
the "myvalue" local variable beyond the for-loop. For
the second loop, the compiler may optimize away the
variable and discard the assignment.

 

[Gerbrand van Dieijen]

Stephen Riehm schreef:

don't those two loops have different semantics, ie: the scope of myvalue?
My understanding would be that myvalue in the first loop would be
overwritten 9 times and then the last value would be available to code
appearing after the loop. The myvalue in the second loop basically has
no effect because it falls out of scope (and into the garbage
collector's hands) as soon as you leave the loop.

Oh, it was just a quick example, there supposed to be done something
with myvalue later in the loop. The point was, myvalue is only needed
inside the loop and not outsite.

int myvalue=0;
for (int i=0;i<10;i++) {
myvalue=calculate(i);
.. do something with myvalue
}
... myvalue no longer needed

for (int i=0;i<10;i++) {
int myvalue=calculate(i);
.. do something with myvalue
}
...my value not needed anymore

I believe this example is somewhere on the web too, but I forgot where
(probably javasoft.com or javaworld.com).

 

[Grant Wagner]

Nope, you're right about the scoping. And best practice is to limit
scope as much as possible.

Right about scoping, but wrong (at least as I understand it) about
eligibility for garbage collection. -myvalue- won't be eligible for
garbage collection until the method exits, because a slot was reserved
for it when the method started. It goes out of scope (visibility to the
remaining source code) but the VM doesn't "lose track of it" until the
method exits.

 

[Ann]

Right about scoping, but wrong (at least as I understand it) about
eligibility for garbage collection. -myvalue- won't be eligible for
garbage collection <insert>

GC only collects objects, primitives like int are not objects.

 

[Tris Orendorff]

don't those two loops have different semantics, ie: the scope of myvalue?
My understanding would be that myvalue in the first loop would be
overwritten 9 times and then the last value would be available to code
appearing after the loop. The myvalue in the second loop basically has
no effect because it falls out of scope (and into the garbage
collector's hands) as soon as you leave the loop.

Almost. myvalue is not garbage collected since it is a primitive (int).


--
Sincerely,

Tris Orendorff

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d++ s+:- a+ C+ UL++++ P+ L+ E- W+ N++ o- K++ w+ O+ M !V PS+ PE Y+ PGP t+ !5 X- R- tv--- b++
DI++ D+ G++ e++ h---- r+++ y+++
------END GEEK CODE BLOCK------