POJO design question (mapping Java Objects to a database)

[hilz]

Sorry for posting this again. I posted it earlier in c.l.j.databases
and i did not get any replies. so i am posting the same question here,
hoping someone will answer.
thanks, and agian, sorry for doing that.



Hi all:
If i have two tables in an existing database, with a relation one-to-many
(one GROUP to many ITEMs)

table GROUP has columns:
ID (long, primary key)
NAME (string)

table ITEM has columns:
ID (long, primary key)
GROUP_ID (long, foreign key)
NAME (string)
ITEM_COST (double)

I want to design POJO classes "Group" and "Item" that map to these tables
my question is about the "Item" class:
should the "Item" class contain a field "groupId" of type Long, with its
getter and setter, or just a reference to a Group object, or both?
for example:

publie class Item{
..
..
Group group; //this?????
public Group getGroup(){return group;}
publie void setGroup(Group group){this.group = group;}


..
..
Long groupId; //or this??????
public Long getGroupId(){return groupId;}
public void setGroupId(Long groupId){this.groupId = groupId;}
..
..

// or both??????
}


thanks
hilz

 

[Andrew Thompson]

Sorry for posting this again. I posted it earlier in c.l.j.databases
and i did not get any replies. so i am posting the same question here,
hoping someone will answer.

Sorry I am unable to assist with your D/B
problem, but thanks for mentioning the
multiple post and explaining why you felt it
was justified (and yes, I agree, 3? days have
passed since the message was posted).

I just thought I'd help in some small way by
providing the link back to that article so
the busy D/B afficionados who read this can
easily confirm the lack of response to that thread..
<http://google.com/groups?th=8bfc6eff5fa38769>

HTH

 

[hilz]

I just thought I'd help in some small way by

providing the link back to that article so
the busy D/B afficionados who read this can
easily confirm the lack of response to that thread..
<http://google.com/groups?th=8bfc6eff5fa38769>

Thanks Andrew,
That was very thoughtful of you.
I should've done it myself!
thanks for your help.
hilz

 

[javadesigner]

table GROUP has columns:
ID (long, primary key)
NAME (string)

table ITEM has columns:
ID (long, primary key)
GROUP_ID (long, foreign key)
NAME (string)
ITEM_COST (double)

I want to design POJO classes "Group" and "Item" that map to these tables

How come I'm seeing the term "POJO" all over the place these
days ? What on earth happened to "object" or "bean" or whatever ?

my question is about the "Item" class:
should the "Item" class contain a field "groupId" of type Long, with its
getter and setter, or just a reference to a Group object, or both?
for example:

publie class Item{
.
.
Group group; //this?????
public Group getGroup(){return group;}
publie void setGroup(Group group){this.group = group;}

Long groupId; //or this??????
public Long getGroupId(){return groupId;}
public void setGroupId(Long groupId){this.groupId = groupI

You're thinking hard about this which is good.

Well, my first suggestion is to use some sort of object-relational
mapping tool. There are many out there, google for this and use
the _simplest_ one you can find.

I can recommend "tablegen".

Don't use anything that required xml declarative programming before
you can generate classes -- too complex and stupid, imho.

Secondly, you (or the framework) should always try to keep a 1-1
mapping between generated objects and database tables. This makes
code more transparent and easier to maintain.

A table because a class and a row becomes a bean. A table-manager
class allows you to save/load beans (rows) into a table.

So:

public Long getGroupId(){return groupId;}
public void setGroupId(Long groupId){this.groupId = groupI

is the better choice. That's how things are laid out in the database
and that's what should happen in your code.

Best regards,

--j

 

[Shane Mingins]

How come I'm seeing the term "POJO" all over the place these
days ? What on earth happened to "object" or "bean" or whatever ?

It was in response to the acronyms for other things in the Java space ...
Martin Fowler thought they needed a fancy name so people would remember them
when considering their options.

http://www.oio.de/m/ejb-persistenz-jdo/fowler-on-pojo-t.htm

Shane

 

[Ryan Stewart]

....

Hi all:
If i have two tables in an existing database, with a relation one-to-many
(one GROUP to many ITEMs)
....
I want to design POJO classes "Group" and "Item" that map to these tables
my question is about the "Item" class:
should the "Item" class contain a field "groupId" of type Long, with its
getter and setter, or just a reference to a Group object, or both?
for example:

....
Look at this first from an object design perspective: does an item have a
group ID? Or does it belong to a group? I would guess the latter. What then
would be your basis for putting a group ID in an item? And why would you
ever put both?? If an item has a reference to its group, then
"item.getGroup().getId()" gives you the group's ID. Clearly from this
perspective, you'd just give item a reference to group. However, you also
have to consider what you're using for persistence. At least one persistence
framework (Apache's OJB) requires you to have both the reference and ID for
some reason.

 

[hilz]

How come I'm seeing the term "POJO" all over the place these

days ? What on earth happened to "object" or "bean" or whatever ?

i don't know! they're all the same i guess! POJO sounds better though,
because it rhymes with mojo!

Well, my first suggestion is to use some sort of object-relational
mapping tool. There are many out there, google for this and use
the _simplest_ one you can find.

I can recommend "tablegen".

Don't use anything that required xml declarative programming before
you can generate classes -- too complex and stupid, imho.

Crazy requirements are preventing me from doing this.
I HAVE to support MSAccess at the beginning, and then later on provide
support for SQLServer and Oracle
pretty crazy huh!
I have looked at hibernate as an O/R mapping framework, but i was not able
to make it work with MSAccess.


i did not know about tablegen before. i just downloaded it, played with it a
little, connected to my Access database, and generated the classes, but it
created all my fields as primitive types. what if values were nulls in the
database? primitive fields need to be objects so that they can preserve the
null values.
and the field names (and getters and setters)'s names are so ugly and not
following any standards. changing them by hand defeats the whole purpose.

thanks
hilz

 

[javadesigner]

i did not know about tablegen before. i just downloaded it, played with it a

little, connected to my Access database, and generated the classes, but it
created all my fields as primitive types. what if values were nulls in the
database? primitive fields need to be objects so that they can preserve the
null values.

Surely it didn't create _all_ fields as primitive types ? I'm sure
it must have created Strings for text types, BigInteger's for
real types and Timestamps for date/time types.

Sure, you'll get an java int for a integer type. But most of these
mapping tools (including, if I recall correctly, tablegen) provide
a isNull(..) method that returns true/false if that primitive type
was actually null in the database.

and the field names (and getters and setters)'s names are so ugly and no
following any standards. changing them by hand defeats the whole purpose.

field names should be exactly the same as the database column names
but I'm not sure what tablegen specifically does. get/set's should
use getFieldName, setFieldName.

Of course, your database column names may not conform to java naming
standards but you can't blame tablegen for that.

The tablegen code is easy enough to hack. You can change it to
generate field names and get/sets in any format you like. This might
be a good exercise anyway because you would spend time getting
familiar with the code which would make you a better programmer,
allow more confidence in the tool and also allow you to modify things
for future projects.

Best regards,

--j

 

[Oscar kind]

I HAVE to support MSAccess at the beginning, and then later on provide
support for SQLServer and Oracle
pretty crazy huh!

Yes, but that's just an opinion.

Some O/R mapping frameworks are available for that trio though. See:
http://c2.com/cgi/wiki?ObjectRelationalToolComparison

The ones I found are:
TopLink: http://otn.oracle.com/products/ias/toplink/index.html
KodoJdo: http://www.solarmetric.com/Software/Kodo_JDO/

I have looked at hibernate as an O/R mapping framework, but i was not able
to make it work with MSAccess.

You can, but I think it's not worth the effort: you'd have to find a
(nearly) equivalent dialect (SQL Server may do, but I honestly don''t
know), and adapt if nescessary. I did found a reference suggesting to
start with the generic dialect (long line; may break):
http://coding.derkeiler.com/Archive/Java/comp.lang.java.databases/2004-01/0010.html

It's much easier to use one of the more simple frameworks though.


[...]

and the field names (and getters and setters)'s names are so ugly and not
following any standards. changing them by hand defeats the whole purpose.

This may be because of the underscores in the original names; a reason why
I use java-like names when designing a database. If, like you, I have to
use an existing database I use Hibernate's feature to map the names
explicitely (but of course, I've never had to support MS Access before).

 

[P.Hill]

It was in response to the acronyms for other things in the Java space ...
Martin Fowler thought they needed a fancy name so people would remember them
when considering their options.

http://www.oio.de/m/ejb-persistenz-jdo/fowler-on-pojo-t.htm

POJO means Plain Old Java Object, so yes its an Object, but it ain't
a necessarily a Bean, yet often is close to being a JavaBean because
it has the simple things like bean-style getters and setters, but it certainly
is NOT an EJB.

-Paul