EJB - Why do we need java persistence on top of a database?

Discussion in 'Java' started by javaguy44, May 12, 2004.

  1. javaguy44

    javaguy44 Guest

    Hi,

    I'm new to EJB, and have done some tutorials etc. but haven't seen the
    need for persistence yet.

    As I understand it, making an object persistent means that the object
    lives forever, even if there's a shut down of the app server. Is this
    right?

    Now my question is, what role does entity bean persistence play, that
    a database cannot do? This is what I don't understand.

    Thanks for helping a EJB newbie
     
    javaguy44, May 12, 2004
    #1
    1. Advertising

  2. javaguy44 wrote:

    > I'm new to EJB, and have done some tutorials etc. but haven't seen the
    > need for persistence yet.
    >
    > As I understand it, making an object persistent means that the object
    > lives forever, even if there's a shut down of the app server. Is this
    > right?


    Depends on how you define "live". The data is preserved and the object
    can be recreated when needed.

    > Now my question is, what role does entity bean persistence play, that
    > a database cannot do? This is what I don't understand.


    It's an additional abstraction layer that achieves a number of things:
    - independance from specific database products
    - transparent clustering
    - declarative transaction definition
     
    Michael Borgwardt, May 12, 2004
    #2
    1. Advertising

  3. javaguy44

    Fedor Guest

    javaguy44 <> wrote:
    > Hi,
    >
    > I'm new to EJB, and have done some tutorials etc. but haven't seen the
    > need for persistence yet.
    >
    > As I understand it, making an object persistent means that the object
    > lives forever, even if there's a shut down of the app server. Is this
    > right?
    >
    > Now my question is, what role does entity bean persistence play, that
    > a database cannot do? This is what I don't understand.
    >

    People always start talking about 'transactions'... Ask
    them what a transaction actually is; that's quite funny :)

    EJB is a hype consisting of some over-engineered frameworks.

    Use plain sockets for communication and plain sql for persistancy.
    That's much cleaner. This kind of stuff seems to be hard for
    average programmers, so they invented all this EJB-crap and
    made some wizards in WSAD......

    Have you ever seen a real working EJB-application? Does amazon,
    google, hotmail use them? I don't tink so... Is it necessary?
    I don't think so....
    When EJB is involved a project it 's all about adding more
    hardware because performance is bad.



    Fedor
     
    Fedor, May 12, 2004
    #3
  4. Fedor wrote:

    > Use plain sockets for communication and plain sql for persistancy.
    > That's much cleaner. This kind of stuff seems to be hard for
    > average programmers, so they invented all this EJB-crap and
    > made some wizards in WSAD......


    Use plain assembler for programs, the "ed" editor to write the code.
    That's much cleaner, but it seems to be hard for average programmers,
    so they invented all this high-level language crap and made decadent
    resource-wasting editors live vi.


    > Have you ever seen a real working EJB-application? Does amazon,
    > google, hotmail use them? I don't tink so... Is it necessary?
    > I don't think so....


    Nice demonstration of the "argument by baseless assertion" technique there...
     
    Michael Borgwardt, May 12, 2004
    #4
  5. javaguy44

    Fedor Guest

    Michael Borgwardt <> wrote:
    > javaguy44 wrote:
    >
    >> I'm new to EJB, and have done some tutorials etc. but haven't seen the
    >> need for persistence yet.
    >>

    > It's an additional abstraction layer that achieves a number of things:
    > - independance from specific database products


    ANSI-SQL is database independent as well, and JDBC wraps
    low-level interfaces to relational databases. If you ever have to
    change SQL, because use want to use a new database (have you
    ever seen a project where they switched to another DBMS?),
    it's always less work than change your EJB-code to conform
    a new EJB-standard used in a new version of the appserver, that
    you have to use because the old one contains memory leaks,
    and security bugs.

    > - transparent clustering


    Most of the time you have to buy more hardware because of the
    overhead of EJB. Processors are fast enough to calculate a
    game off chess 10 ply deep.
    999 out of 1000 projects need clustering. If you write efficient
    code, there is no need to cluster. And still, there is no need
    to use EJB as long as sessions are serializable and your app-server
    supports cloning, you can do load balancing.

    > - declarative transaction definition
    >

    transaction? what's that?

    Isn't a transaction an application level issue? Isn't that
    'business logic'? And with JDBC you can just do rollback().
    'declarative transactions' on the application level can
    be implemented using;

    if (enoughCredits)
    execute();
    else
    rollBack();


    Fedor.
     
    Fedor, May 12, 2004
    #5
  6. javaguy44

    Fedor Guest

    Michael Borgwardt <> wrote:
    > Fedor wrote:
    >
    >> Use plain sockets for communication and plain sql for persistancy.
    >> That's much cleaner. This kind of stuff seems to be hard for
    >> average programmers, so they invented all this EJB-crap and
    >> made some wizards in WSAD......

    >
    > Use plain assembler for programs, the "ed" editor to write the code.
    > That's much cleaner, but it seems to be hard for average programmers,
    > so they invented all this high-level language crap and made decadent
    > resource-wasting editors live vi.
    >

    Assembly language not platform independent and therefor it could
    be evil. EJB is even more evil, because it's EJB-spec-version-dependent.



    Fedor.
     
    Fedor, May 12, 2004
    #6
  7. javaguy44

    Ryan Stewart Guest

    "Fedor" <> wrote in message
    news:40a1feb0$0$97889$4all.nl...
    > Michael Borgwardt <> wrote:
    > > javaguy44 wrote:
    > >
    > >> I'm new to EJB, and have done some tutorials etc. but haven't seen the
    > >> need for persistence yet.
    > >>

    > > It's an additional abstraction layer that achieves a number of things:
    > > - independance from specific database products

    >
    > ANSI-SQL is database independent as well, and JDBC wraps
    > low-level interfaces to relational databases. If you ever have to
    > change SQL, because use want to use a new database (have you
    > ever seen a project where they switched to another DBMS?),

    Yes, several in the past year.

    > it's always less work than change your EJB-code to conform
    > a new EJB-standard used in a new version of the appserver, that
    > you have to use because the old one contains memory leaks,
    > and security bugs.
    >

    I don't use EJB's, but using any of the persistence methods we use is *many*
    times easier and less work than managing SQL statements.

    > > - transparent clustering

    >
    > Most of the time you have to buy more hardware because of the
    > overhead of EJB. Processors are fast enough to calculate a
    > game off chess 10 ply deep.
    > 999 out of 1000 projects need clustering. If you write efficient
    > code, there is no need to cluster. And still, there is no need
    > to use EJB as long as sessions are serializable and your app-server
    > supports cloning, you can do load balancing.
    >

    So don't use EJB's if your application doesn't need them, but use some
    persistence mechanism.

    > > - declarative transaction definition
    > >

    > transaction? what's that?
    >

    A unit of interaction with the database which is all or none. It usually
    consists of multiple updates (not in the SQL sense) to a database that must
    be done as a unit to keep the database in a valid state. No changes are made
    to the database until the entire transaction is complete. If any of the
    updates fail, the transaction is rolled back so that none of them are
    carried out. If all are successful, the transaction is committed, and the
    changes are actually made.

    > Isn't a transaction an application level issue? Isn't that
    > 'business logic'?

    Not necessarily.

    > And with JDBC you can just do rollback().
    > 'declarative transactions' on the application level can
    > be implemented using;
    >
    > if (enoughCredits)
    > execute();
    > else
    > rollBack();
    >

    What's your point? Any good persistence mechanism will allow this if you
    really need it. I've never had reason to investigate EJBs myself, but
    advising someone to use JDBC when you don't know his/her situation is bad.
    JDBC is suitable only for the simplest applications and should still be used
    in conjunction with some design pattern that will separate the database code
    from the business logic. For anything besides very basic applications, look
    into an object to relational architecture like TopLink, OJB, Hibernate, etc.
     
    Ryan Stewart, May 12, 2004
    #7
  8. Fedor wrote:

    > Isn't a transaction an application level issue? Isn't that
    > 'business logic'? And with JDBC you can just do rollback().
    > 'declarative transactions' on the application level can
    > be implemented using;
    >
    > if (enoughCredits)
    > execute();
    > else
    > rollBack();


    A J2EE transaction may involve manipulation of many resources, including
    one or many databases, business objects, and a few other things. J2EE
    transactions provide a configurable level of isolation of seperate
    concurrent transactions, and support for rolling back the whole thing.
    The are much broader in scope than plain database transactions. J2EE
    also provides for (but does not require) "container managed
    transactions", which can significantly ease the burden of supporting
    transactionality in a J2EE application.


    John Bollinger
     
    John C. Bollinger, May 12, 2004
    #8
  9. javaguy44

    Roedy Green Guest

    On 12 May 2004 02:20:57 -0700, (javaguy44) wrote
    or quoted :

    >Now my question is, what role does entity bean persistence play, that
    >a database cannot do? This is what I don't understand.


    See http://mindprod.com/jgloss/pod.html

    The persistent object model allows for complex connections between
    objects. Before you can use an SQL database for persistence, you have
    to figure out how to store everything in tables.

    PODs store complete objects. SQL stores fields.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, May 12, 2004
    #9
  10. javaguy44

    Fedor Guest

    Roedy Green <> wrote:
    > On 12 May 2004 02:20:57 -0700, (javaguy44) wrote
    > or quoted :
    >
    >>Now my question is, what role does entity bean persistence play, that
    >>a database cannot do? This is what I don't understand.

    >
    > See http://mindprod.com/jgloss/pod.html
    >
    > The persistent object model allows for complex connections between
    > objects. Before you can use an SQL database for persistence, you have
    > to figure out how to store everything in tables.
    >
    > PODs store complete objects. SQL stores fields.
    >

    The objects living in java are the same as the objects living
    in the database. A relational database is much more powerfull
    and - in my opinion - usefull to exploit it's functionality.

    A relational database is just a complex datastructure
    which is able to manage large amounts of data. On top
    of that you build a java-application in which you have
    different objects, not copies of the database tabels!

    For instance; in the database you have a table containing
    customer data, an other table contains product information,
    an you have tables containing orders and order lines.

    Now, you can build a java application for planning
    the routes of truck drivers and the way the truck should
    be loaded. You're getting nowhere with object-persistance
    stuff? You don't even want orderline, orders, customers
    and products in your java-app. Your business logic on
    the application level is implemented in java classes
    like 'route', 'delivery' etc... These objects are constructed
    by doing intelligent SQL-queries which cannot be generated
    by frameworks.

    I think this discussion is about developing an application
    by starting with a relational database (which based on
    mathematical rules) vs. starting with some object-model
    (which is based on some recent software engineering 'theory').

    Am I wrong here?
     
    Fedor, May 13, 2004
    #10
  11. javaguy44

    Ryan Stewart Guest

    "Fedor" <> wrote in message
    news:40a31b9d$0$175$4all.nl...
    > Roedy Green <> wrote:
    > > On 12 May 2004 02:20:57 -0700, (javaguy44) wrote
    > > or quoted :
    > >
    > >>Now my question is, what role does entity bean persistence play, that
    > >>a database cannot do? This is what I don't understand.

    > >
    > > See http://mindprod.com/jgloss/pod.html
    > >
    > > The persistent object model allows for complex connections between
    > > objects. Before you can use an SQL database for persistence, you have
    > > to figure out how to store everything in tables.
    > >
    > > PODs store complete objects. SQL stores fields.
    > >

    > The objects living in java are the same as the objects living
    > in the database. A relational database is much more powerfull
    > and - in my opinion - usefull to exploit it's functionality.
    >

    Objects in Java and "objects" in a database are not at all the same. You
    might call them entities, but not objects. Databases support object oriented
    design in limited, primitive ways only. And a database is more powerful and
    useful than what? Java? Only at the task it was designed for: data
    management.

    > A relational database is just a complex datastructure
    > which is able to manage large amounts of data. On top
    > of that you build a java-application in which you have
    > different objects, not copies of the database tabels!
    >

    You don't build an application on a database. You design a database to back
    an application. Objects are not quite copies of tables, but there should be
    a strong resemblance.

    > For instance; in the database you have a table containing
    > customer data, an other table contains product information,
    > an you have tables containing orders and order lines.
    >
    > Now, you can build a java application for planning
    > the routes of truck drivers and the way the truck should
    > be loaded. You're getting nowhere with object-persistance
    > stuff? You don't even want orderline, orders, customers
    > and products in your java-app.

    Wrong on several counts. If orderline, orders, customers, and products are
    central to your application, then you want them represented as objects.

    > Your business logic on
    > the application level is implemented in java classes
    > like 'route', 'delivery' etc...

    It's fine that (most of) your business object is implemented elsewhere, but
    the way you describe, it would be intertwined with your database, which is
    bad.

    > These objects are constructed
    > by doing intelligent SQL-queries which cannot be generated
    > by frameworks.
    >

    Even ignoring what I've already said, this is pure rubbish. You need to do
    some research before you make such assertions. If anything, a good
    persistence framework allows you to write extremely complex queries much
    more easily than with pure SQL. That's besides the fact that frameworks are
    much faster than SQL because of object caching.

    > I think this discussion is about developing an application
    > by starting with a relational database (which based on
    > mathematical rules) vs. starting with some object-model
    > (which is based on some recent software engineering 'theory').
    >
    > Am I wrong here?
    >

    Perhaps not, for maybe the first time in this post. But if you're suggesting
    that application design should begin by designing a database, I have to
    disagree. If you're suggesting that a database is based on rules and an
    object model is not, I have to disagree again. And if you're suggesting that
    a database is capable of replacing an object model, I have to laugh in your
    face. Trying to design from the database to an object model will lead you to
    coerce objects into unnatural uses and states, or at best, to use only
    simple objects as data representations. Designing an object model to
    accomplish your task and backing it by a database leaves you open to using
    the full power of Java as an object-oriented language, which is where its
    power lies. I've seen projects wilt and die because too much work is done
    directly from the database rather than using objects to manage and act on
    the data.
     
    Ryan Stewart, May 13, 2004
    #11
  12. javaguy44

    Bryce Guest

    On 12 May 2004 10:38:40 GMT, Fedor <> wrote:

    >Michael Borgwardt <> wrote:
    >> javaguy44 wrote:
    >>
    >>> I'm new to EJB, and have done some tutorials etc. but haven't seen the
    >>> need for persistence yet.
    >>>

    >> It's an additional abstraction layer that achieves a number of things:
    >> - independance from specific database products

    >
    >ANSI-SQL is database independent as well, and JDBC wraps
    >low-level interfaces to relational databases. If you ever have to
    >change SQL, because use want to use a new database (have you
    >ever seen a project where they switched to another DBMS?),


    Actually... Yes. Many times.

    --
    now with more cowbell
     
    Bryce, May 13, 2004
    #12
  13. javaguy44

    Fedor Guest

    Ryan Stewart <> wrote:
    >> > PODs store complete objects. SQL stores fields.
    >> >

    >> The objects living in java are the same as the objects living
    >> in the database. A relational database is much more powerfull
    >> and - in my opinion - usefull to exploit it's functionality.
    >>

    > Objects in Java and "objects" in a database are not at all the same. You
    > might call them entities, but not objects. Databases support object oriented
    > design in limited, primitive ways only. And a database is more powerful and
    > useful than what? Java? Only at the task it was designed for: data
    > management.
    >

    Entities, objects, whatever...it's just a matter of definition.
    Call a table a class and call a record an instance. The only
    difference is behavior (methods) which is embedded in an object.
    Behavior persistance is nonsense and there is no need to store
    it in a relational database, because the only relation the
    behavior has is a relation with the object it belongs too.
    Perhaps state is important to store, or is it not? State is
    just a matter of values in data members.

    Relational database fully support object oriented design. Object
    oriented languages do not. In a java class you have a lot
    of references to other objects, like a class called Person
    with to strings in it; name and address.
    How do you know in advance if you want one class called
    'Person' or two classes: 'String' and 'Person'. What's the
    relation between them? Or is there no relation and should
    we just design it as one class? There is always a matter
    of 'common sense' when designing such stuff. A java
    class typically has many relations with other classes.
    Almost each datamember is a relation with another
    class.

    When you just focus on data, you don't have these
    problems. You don't have to group data in classes.
    You can classify the data by firing SQL-queries on
    your tables. That's very powerfull and (when setup
    correctly) also very fast.

    >> A relational database is just a complex datastructure
    >> which is able to manage large amounts of data. On top
    >> of that you build a java-application in which you have
    >> different objects, not copies of the database tabels!
    >>

    > You don't build an application on a database. You design a database to back
    > an application. Objects are not quite copies of tables, but there should be
    > a strong resemblance.
    >

    That's just my point. Since OO, people started to abuse
    relational databases for this purpose. It's a new way
    of desiging applications. In my opinion a properly designed
    database in which data cannot be corrupted (in terms
    of application logic) should be the core of an application.
    On top of it, you can build anything you like.

    If you have a database with customers, orders, orderlines
    and products you can create applications for:

    - planning routes for delivery of goods
    - marketing purposes
    - an online ordering system for customers
    - a planning system for the busy days around christmas

    etc.

    If you design in the OO way and use the relational
    database just for object persistancy, the database
    will be bloated at the end.

    >> For instance; in the database you have a table containing
    >> customer data, an other table contains product information,
    >> an you have tables containing orders and order lines.
    >>
    >> Now, you can build a java application for planning
    >> the routes of truck drivers and the way the truck should
    >> be loaded. You're getting nowhere with object-persistance
    >> stuff? You don't even want orderline, orders, customers
    >> and products in your java-app.

    > Wrong on several counts. If orderline, orders, customers, and products are
    > central to your application, then you want them represented as objects.
    >

    I do not agree. Truck drivers have nothing to do with customers,
    orders, and orderlines. They only want to know about adresses and
    boxes with goodies. These objects live in the application for the
    truck drivers and is build around an existing database used
    for making orders.

    >> Your business logic on
    >> the application level is implemented in java classes
    >> like 'route', 'delivery' etc...

    > It's fine that (most of) your business object is implemented elsewhere, but
    > the way you describe, it would be intertwined with your database, which is
    > bad.
    >

    Why is that bad?
    Is it bad when I have fine grained data in my database and
    some more raw objects in my application? That's just the power
    of a relational system...with intelligent SQL queries you can
    any dataset (read: object) you like.

    >> These objects are constructed
    >> by doing intelligent SQL-queries which cannot be generated
    >> by frameworks.
    >>

    > Even ignoring what I've already said, this is pure rubbish. You need to do
    > some research before you make such assertions. If anything, a good
    > persistence framework allows you to write extremely complex queries much
    > more easily than with pure SQL. That's besides the fact that frameworks are
    > much faster than SQL because of object caching.
    >

    Because of object caching? A query generated by a persistance framework
    can't be more efficient than a hand crated query, just because it's
    more high level.

    >> I think this discussion is about developing an application
    >> by starting with a relational database (which based on
    >> mathematical rules) vs. starting with some object-model
    >> (which is based on some recent software engineering 'theory').
    >>
    >> Am I wrong here?
    >>

    > Perhaps not, for maybe the first time in this post. But if you're suggesting
    > that application design should begin by designing a database, I have to
    > disagree. If you're suggesting that a database is based on rules and an
    > object model is not, I have to disagree again. And if you're suggesting that


    In my opinion a database is the perfect place for implementing
    business logic!

    > a database is capable of replacing an object model, I have to laugh in your
    > face. Trying to design from the database to an object model will lead you to
    > coerce objects into unnatural uses and states, or at best, to use only
    > simple objects as data representations. Designing an object model to
    > accomplish your task and backing it by a database leaves you open to using
    > the full power of Java as an object-oriented language, which is where its
    > power lies. I've seen projects wilt and die because too much work is done
    > directly from the database rather than using objects to manage and act on
    > the data.
    >
    >

    But what's an object in your opinion? don't you mean a 'class'?


    Fedor
     
    Fedor, May 13, 2004
    #13
  14. javaguy44

    Ryan Stewart Guest

    "Fedor" <> wrote in message
    news:40a3cdb9$0$179$4all.nl...
    > Entities, objects, whatever...it's just a matter of definition.
    > Call a table a class and call a record an instance. The only
    > difference is behavior (methods) which is embedded in an object.
    > Behavior persistance is nonsense and there is no need to store
    > it in a relational database, because the only relation the
    > behavior has is a relation with the object it belongs too.
    > Perhaps state is important to store, or is it not? State is
    > just a matter of values in data members.

    Granted, but that's the point. Databases are for storing data, not for being
    an object model.

    > Relational database fully support object oriented design. Object
    > oriented languages do not.

    That's absurd. How do you support this statement?

    > In a java class you have a lot
    > of references to other objects, like a class called Person
    > with to strings in it; name and address.

    Name might not be a String, and address certainly wouldn't be.

    > How do you know in advance if you want one class called
    > 'Person' or two classes: 'String' and 'Person'. What's the
    > relation between them?

    Not following you here.

    > Or is there no relation and should
    > we just design it as one class?

    Design what as one class?

    > There is always a matter
    > of 'common sense' when designing such stuff. A java
    > class typically has many relations with other classes.
    > Almost each datamember is a relation with another
    > class.

    Of course you have to use common sense. It's also beneficial to follow
    certain standards. I wouldn't agree that most data members are relations to
    other classes, though.

    > When you just focus on data, you don't have these
    > problems.

    Your "problems" made no sense to me.

    > You don't have to group data in classes.

    You never *have* to group data in classes. But most sane people *want* to.

    > You can classify the data by firing SQL-queries on
    > your tables. That's very powerfull and (when setup
    > correctly) also very fast.

    As fast as accessing local memory? Sorry, not possible except *possibly* if
    your database is also local: an improbable scenario for anything but a tiny
    enterprise system. And please tell me you at least use connection pooling
    when you're doing all this SQL stuff.

    > >> A relational database is just a complex datastructure
    > >> which is able to manage large amounts of data. On top
    > >> of that you build a java-application in which you have
    > >> different objects, not copies of the database tabels!
    > >>

    > > You don't build an application on a database. You design a database to

    back
    > > an application. Objects are not quite copies of tables, but there should

    be
    > > a strong resemblance.
    > >

    > That's just my point. Since OO, people started to abuse
    > relational databases for this purpose.

    Abuse? What purpose?

    > It's a new way
    > of desiging applications. In my opinion a properly designed
    > database in which data cannot be corrupted (in terms
    > of application logic) should be the core of an application.
    > On top of it, you can build anything you like.

    Absolutely. OOD doesn't dictate a badly designed database. But a database is
    not the "core of an application". It's the data store of an application. An
    application can run fine without a database. It would just have a short
    memory.

    > If you have a database with customers, orders, orderlines
    > and products you can create applications for:
    >
    > - planning routes for delivery of goods
    > - marketing purposes
    > - an online ordering system for customers
    > - a planning system for the busy days around christmas
    >
    > etc.
    >
    > If you design in the OO way and use the relational
    > database just for object persistancy, the database
    > will be bloated at the end.

    False in my experience. On what grounds do you base this statement? Besides,
    the database isn't necessarily about object persistence. It's about data
    persistence.

    > >> For instance; in the database you have a table containing
    > >> customer data, an other table contains product information,
    > >> an you have tables containing orders and order lines.
    > >>
    > >> Now, you can build a java application for planning
    > >> the routes of truck drivers and the way the truck should
    > >> be loaded. You're getting nowhere with object-persistance
    > >> stuff? You don't even want orderline, orders, customers
    > >> and products in your java-app.

    > > Wrong on several counts. If orderline, orders, customers, and products

    are
    > > central to your application, then you want them represented as objects.
    > >

    > I do not agree. Truck drivers have nothing to do with customers,
    > orders, and orderlines. They only want to know about adresses and
    > boxes with goodies. These objects live in the application for the
    > truck drivers and is build around an existing database used
    > for making orders.

    You're blurring the lines here. If the application is for calculating
    trucking routes, then what do customers and products have to do with it?
    Even orders would be stretching it I think. This data would obviously have
    to be processed somewhere and handed off to your application in some form.
    On the other hand, though, I have to disagree with your statement that truck
    drivers have nothing to do with customers or orders (still not sure what you
    mean by orderlines: it's vague). What is the driver ultimately carrying?
    Orders. And where is he taking them? To customers.

    > >> Your business logic on
    > >> the application level is implemented in java classes
    > >> like 'route', 'delivery' etc...

    > > It's fine that (most of) your business object is implemented elsewhere,

    but
    I meant "business logic" there.

    > > the way you describe, it would be intertwined with your database, which

    is
    > > bad.
    > >

    > Why is that bad?

    Primarily because it's generally accepted that business logic should all be
    in one place, and that place is not a database.

    > Is it bad when I have fine grained data in my database and
    > some more raw objects in my application? That's just the power
    > of a relational system...with intelligent SQL queries you can
    > any dataset (read: object) you like.

    Data is data. Make it as fine or coarse as you like. What does that have to
    do with anything? And what is a "raw object"?

    > >> These objects are constructed
    > >> by doing intelligent SQL-queries which cannot be generated
    > >> by frameworks.
    > >>

    > > Even ignoring what I've already said, this is pure rubbish. You need to

    do
    > > some research before you make such assertions. If anything, a good
    > > persistence framework allows you to write extremely complex queries much
    > > more easily than with pure SQL. That's besides the fact that frameworks

    are
    > > much faster than SQL because of object caching.
    > >

    > Because of object caching? A query generated by a persistance framework
    > can't be more efficient than a hand crated query, just because it's
    > more high level.

    Maybe, maybe not. Have you tested that? Besides, the issue is not whether
    the framework generates more or less efficient queries. The issue is that
    a framework generates less queries than directly accessing the database any
    time data is needed. It's the queries themselves that are expensive.

    > >> I think this discussion is about developing an application
    > >> by starting with a relational database (which based on
    > >> mathematical rules) vs. starting with some object-model
    > >> (which is based on some recent software engineering 'theory').
    > >>
    > >> Am I wrong here?
    > >>

    > > Perhaps not, for maybe the first time in this post. But if you're

    suggesting
    > > that application design should begin by designing a database, I have to
    > > disagree. If you're suggesting that a database is based on rules and an
    > > object model is not, I have to disagree again. And if you're suggesting

    that
    >
    > In my opinion a database is the perfect place for implementing
    > business logic!

    You must have a different definition of business logic. You can't
    "implement" business logic with a database, except maybe in limited ways.
    Business logic is basically the code that makes the application do something
    useful.

    > > a database is capable of replacing an object model, I have to laugh in

    your
    > > face. Trying to design from the database to an object model will lead

    you to
    > > coerce objects into unnatural uses and states, or at best, to use only
    > > simple objects as data representations. Designing an object model to
    > > accomplish your task and backing it by a database leaves you open to

    using
    > > the full power of Java as an object-oriented language, which is where

    its
    > > power lies. I've seen projects wilt and die because too much work is

    done
    > > directly from the database rather than using objects to manage and act

    on
    > > the data.
    > >
    > >

    > But what's an object in your opinion? don't you mean a 'class'?

    No. A class is a template for creating an object. By "object", I mean an
    object from an object-oriented point of view. In this case, I'm specifically
    talking about a Java object. Objects are essentially where you implement
    your application's business logic. Good OOD leads to clean, easily
    maintainable code and logic intuitive to others versed in it. From reading
    your most recent post, you seem to be confused on the purpose of EJB.
    They're not something that would replace a database. They're something that
    would use a database to store their state like a persistence framework does
    for normal objects.
     
    Ryan Stewart, May 16, 2004
    #14
  15. javaguy44

    Roedy Green Guest

    On Sat, 15 May 2004 19:34:05 -0500, "Ryan Stewart"
    <> wrote or quoted :

    >> Relational database fully support object oriented design. Object
    >> oriented languages do not.


    you have that backwards. There is no inheritance, no references etc
    etc in SQL. You do have persistence.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, May 16, 2004
    #15
  16. javaguy44

    Sudsy Guest

    Ryan Stewart wrote:
    <snip>
    > Primarily because it's generally accepted that business logic should all be
    > in one place, and that place is not a database.

    </snip>
    <snip>
    > You must have a different definition of business logic. You can't
    > "implement" business logic with a database, except maybe in limited ways.

    </snip>

    These two comments illuminate a culture clash: the database vendors want
    you to implement business logic via stored procedures (and/or triggers)
    in the database engine. Sun wants to move it into the J2EE tier through
    the use of session EJBs.
    I subscribe to the latter approach. I want to be able to replace my J2EE
    engine or my database engine as situations dictate. I don't want to be
    tied to PL/SQL or any other proprietary access method.
    That's also why I'm keen on entity EJBs. It's an additional layer of
    abstraction which enhances both portability and scalability.
    So I'm on your side, Ryan.
    YMMV
     
    Sudsy, May 16, 2004
    #16
  17. javaguy44

    Fedor Guest

    Roedy Green <> wrote:
    > On Sat, 15 May 2004 19:34:05 -0500, "Ryan Stewart"
    > <> wrote or quoted :
    >
    >>> Relational database fully support object oriented design. Object
    >>> oriented languages do not.

    >
    > you have that backwards. There is no inheritance, no references etc
    > etc in SQL. You do have persistence.
    >

    I was talking about relationships between objects. In
    a database you have foreing keys, but what does java offer?
    It only offers datamembers, but on the other side, each
    real-life Java class contains hundreds of relations with
    other classes...Strings as datamembers, HashMaps for book
    keeping etc.

    If you're starting to design a system using class diagrams
    it's much more easier to implement it in a relational
    database. A class diagram is a description showing
    relations, between 'things' containing data and functions.
    Only functions are missing in a relational database
    (perhaps you can implement them with stored procedures
    and some coding conventions).

    When you try to implement the same class diagram
    in a language like Java, it'll result in a bunch
    of struct-classes containing just datamembers and
    getters and setters. I always see that in projects.
    In a lot of projects this approach seems not that
    practical. For example, if you designed some class
    diagram with a Person, an Insurance and everything
    works fine and the customer wants insurances for
    animals which do have a relation with an Insurance
    but with a Person too... it surely creates bloat.

    Perhaps people start adding a class Animal and
    a class Human which inherit stuff from an
    InsuredThing-class. Others invent an InsuranceType
    -class and rename the Person-class to Thing...etc...
    there are a lot of options and when requirements change
    you have to adapt a lot of code.

    In a relational database it may be easier, but sometimes
    more difficult to adapt the design. I'm not a
    relational database-evangelist. My only point is
    that you have to push these kinds of fundamental
    business logic (not rules) to a lower level; the
    database. When things need to be changed, the only
    thing you have to change is an SQL-query.
    If you have a table X in the database, this doesn't mean
    that you have to program a class called X. That 's
    just overhead. In case of the Person-Insurance-Animal
    thing an application would do with a class like;

    InsuranceOverview
    {
    public InsuranceOverview(int customerID)
    {
    // some jdbc-stuff
    // and a simple query to join
    // all tables you need

    // some stuff to initialize datamembers
    }
    public boolean load(int customerID)
    {//
    }
    public boolean sendBill(int month)
    {//
    }
    }


    With basic OO-theory and 'good practice' EJB-programming
    you just cannot write elegant code like this :)


    fedor
     
    Fedor, May 17, 2004
    #17
  18. javaguy44

    Chris Smith Guest

    Fedor wrote:
    > >>> Relational database fully support object oriented design. Object
    > >>> oriented languages do not.


    > I was talking about relationships between objects. In
    > a database you have foreing keys, but what does java offer?


    Java's object model is at least as capable as foreign keys, if that's
    what you mean. You can implement any data in a relational model, or in
    Java's object model... but it will be far easier to understand in a Java
    object model.

    That's only natural. The relational model is an attempt to coerce real-
    world concepts into a mathematical concept so that data can be expressed
    in a canonical way that's not too dependent on the way it's used by the
    application, and so that optimizations can be applied to retrieve
    arbitrary sets of data quickly. And those are important requirements,
    but they are necessarily abstracted from the application...
    intentionally. The Java object model, on the other hand, is designed to
    build abstractions of real-world concepts within a problem domain (that
    is, in a way that's convenient for the kind of work that's going to be
    done).

    Naturally, it's far easier to design using Java objects (which are
    intended for that purpose), and then figure out how that maps to your
    universal data model in the database after the fact. As for the
    database side, it can sometimes be very important to design correctly
    from scratch there, too, if the database will be shared by a number of
    software systems with different tasks and goals; but if the database
    will be private to the application, it's often best to just let an O/R
    mapper or EJB container generate a schema for you, and tune from there.

    > If you're starting to design a system using class diagrams
    > it's much more easier to implement it in a relational
    > database.


    Well, no it's not. I don't know what else to say. A class diagram is
    used specifically because it keeps common concerns together; everything
    relevant about a type of object in a software system and its
    relationships to other objects (within the context of the diagram
    itself) is described on that diagram. You simply can't express that
    using a relational database design tool (such as, say, an ERD).

    *After* you know how the core software architecture is going to work,
    then the task is to discover which small *subset* of your software
    design is relevant to persistence, and design that in. In a typical
    software system, far more classes will be transient than persistent, and
    some classes may be relevant to persistence in some ways, but also have
    transient aspects to them.

    > When you try to implement the same class diagram
    > in a language like Java, it'll result in a bunch
    > of struct-classes containing just datamembers and
    > getters and setters. I always see that in projects.


    Perhaps you work on the wrong projects, or perhaps your projects are
    designed by people who don't understand software architecture and think
    that UML class diagrams are equivalent to ERDs. Unfortunately, UML
    diagrams can only help good designers communicate their designs; no
    diagramming technique can cause bad designers to produce good design.
    Starting with ERDs, though, can only make it harder for software
    designers to communicate designs of dynamic software... unless the only
    point of the software is to create, store, and retrieve data from
    database tables; and how often is that the case?

    > In a lot of projects this approach seems not that
    > practical. For example, if you designed some class
    > diagram with a Person, an Insurance and everything
    > works fine and the customer wants insurances for
    > animals which do have a relation with an Insurance
    > but with a Person too... it surely creates bloat.


    Surely, the correct approach would be to use inheritance to define
    several types of insurance, each type of which would know what it
    applies to. Otherwise, you end up with something silly like keeping
    track of the address for the property that's covered by a life insurance
    policy. How to store this in the database is another matter, but the
    correct abstraction is basically obvious.

    > Perhaps people start adding a class Animal and
    > a class Human which inherit stuff from an
    > InsuredThing-class.


    I'm pretty sure no competent OO designer would ever inherit a class
    called "Person" from a class called "InsuredThing". That's just dumb.

    > there are a lot of options and when requirements change
    > you have to adapt a lot of code.


    [...]

    > When things need to be changed, the only
    > thing you have to change is an SQL-query.


    Java and SQL are both languages. In either case, you have to update
    code when the means of representing data has changed. It's quite
    unlikely that only one SQL query would need to be changed. In fact,
    unless the application is particularly trivial, you'll probably end up
    updating some code in Java that generates SQL queries to run against the
    database. You can do that yourself, or you can let an O/R mapper such
    as EJB-CMP (or Hibernate or some JDO implementation or whatever) do it
    for you. That's up to you, but don't make it sound so trivial. It only
    is if your application is trivial.

    > If you have a table X in the database, this doesn't mean
    > that you have to program a class called X.


    Of course not. It's certainly important to remember that applications
    only need to deal with potentially simplified subsets of data from a
    cross-application database. (If the database is application-private,
    then you probably just generated a schema from your code anyway so the
    question is moot.)

    However, neither can you ignore the data complexity at the application
    level. That application is probably responsible for a good bit of logic
    that depends on various details of the data, and needs to present that
    to the user. Your creation of a class with a few methods in it is a
    little oversimplifying.

    > With basic OO-theory and 'good practice' EJB-programming
    > you just cannot write elegant code like this :)


    I won't speak for the EJB environment (which is rather restrictive in
    terms of what can be done), but you certainly can write far more elegant
    (and what's more, functional) code than that.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, May 18, 2004
    #18
    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. javaguy44
    Replies:
    10
    Views:
    1,011
    Michael Berg
    May 18, 2004
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,263
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    2
    Views:
    466
    Colin Lanning
    Mar 14, 2007
  4. Kenneth P. Turvey

    Java Persistence API and persistence.xml

    Kenneth P. Turvey, Mar 15, 2008, in forum: Java
    Replies:
    2
    Views:
    17,514
    Kenneth P. Turvey
    Mar 16, 2008
  5. Raymond Schanks
    Replies:
    0
    Views:
    700
    Raymond Schanks
    Aug 3, 2010
Loading...

Share This Page