POJO design question (mapping Java Objects to a database)

Discussion in 'Java' started by hilz, Jul 26, 2004.

  1. hilz

    hilz Guest

    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
    hilz, Jul 26, 2004
    #1
    1. Advertising

  2. On Mon, 26 Jul 2004 16:07:00 GMT, hilz wrote:

    > 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

    --
    Andrew Thompson
    http://www.PhySci.org/ Open-source software suite
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.1point1C.org/ Science & Technology
    Andrew Thompson, Jul 26, 2004
    #2
    1. Advertising

  3. hilz

    hilz Guest

    > 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
    hilz, Jul 26, 2004
    #3
  4. hilz

    javadesigner Guest


    > 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
    javadesigner, Jul 26, 2004
    #4
  5. "javadesigner" <> wrote in message
    news:ce3ksn$4snr$...
    >
    > 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


    --
    There are three kinds of untruths: Lies, Damn Lies, and Statistics. --
    Attributed to Benjamin Disraeli by Mark Twain
    Shane Mingins, Jul 26, 2004
    #5
  6. hilz

    Ryan Stewart Guest

    "hilz" <> wrote in message
    news:E_9Nc.5490$...
    ....
    > 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.
    Ryan Stewart, Jul 26, 2004
    #6
  7. hilz

    hilz Guest

    > 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
    hilz, Jul 26, 2004
    #7
  8. hilz

    javadesigner Guest

    > 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
    javadesigner, Jul 26, 2004
    #8
  9. hilz

    Oscar kind Guest

    hilz <> wrote:
    > 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).



    --
    Oscar Kind http://home.hccnet.nl/okind/
    Software Developer for contact information, see website

    PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
    Oscar kind, Jul 27, 2004
    #9
  10. hilz

    P.Hill Guest

    Shane Mingins wrote:

    > "javadesigner" <> wrote in message
    > news:ce3ksn$4snr$...
    >
    >>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


    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
    P.Hill, Jul 27, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott Balmos
    Replies:
    1
    Views:
    637
    Steve W. Jackson
    Aug 31, 2005
  2. mdjj
    Replies:
    0
    Views:
    728
  3. Sundar
    Replies:
    2
    Views:
    611
    RedGrittyBrick
    Jan 19, 2008
  4. Java coder

    Simple/pojo loc parser for java

    Java coder, Sep 6, 2010, in forum: Java
    Replies:
    2
    Views:
    560
    John B. Matthews
    Sep 6, 2010
Loading...

Share This Page