Spring/hibernate and JDBC

Discussion in 'Java' started by Jack, Jul 9, 2011.

  1. Jack

    Jack Guest

    With spring and hibernate so popular now, is there anybody still only
    use JDBC to write database application code? Thanks.
    Jack, Jul 9, 2011
    #1
    1. Advertising

  2. Jack

    markspace Guest

    On 7/9/2011 2:56 PM, Jack wrote:
    > With spring and hibernate so popular now, is there anybody still only
    > use JDBC to write database application code? Thanks.



    I'm sure someone is, but yes I assume that JPA & Hibernate and
    dependency injection frameworks like Spring and JSF have become the norm.

    Still good to know what JDBC is and does, since it's used by JPA and
    Hibernate (et al.).
    markspace, Jul 10, 2011
    #2
    1. Advertising

  3. Jack

    Jack Guest

    On Jul 9, 4:01 pm, markspace <-@.> wrote:
    > On 7/9/2011 2:56 PM, Jack wrote:
    >
    > > With spring and hibernate so popular now, is there anybody still only
    > > use JDBC to write database application code? Thanks.

    >
    > I'm sure someone is, but yes I assume that JPA & Hibernate and
    > dependency injection frameworks like Spring and JSF have become the norm.
    >
    > Still good to know what JDBC is and does, since it's used by JPA and
    > Hibernate (et al.).


    What are the pros and cons of using Spring/hibernate and JDBC?

    Thanks.
    Jack, Jul 10, 2011
    #3
  4. Jack

    Jack Guest

    On Jul 9, 4:01 pm, markspace <-@.> wrote:
    > On 7/9/2011 2:56 PM, Jack wrote:
    >
    > > With spring and hibernate so popular now, is there anybody still only
    > > use JDBC to write database application code? Thanks.

    >
    > I'm sure someone is, but yes I assume that JPA & Hibernate and
    > dependency injection frameworks like Spring and JSF have become the norm.
    >
    > Still good to know what JDBC is and does, since it's used by JPA and
    > Hibernate (et al.).


    Is using JDBC to access database more efficient than using
    Spring/hibernate?
    Jack, Jul 10, 2011
    #4
  5. Jack

    Aéris Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Le 09/07/2011 23:56, Jack a écrit :
    > With spring and hibernate so popular now, is there anybody still only
    > use JDBC to write database application code? Thanks.


    Unfortunately, yes…

    With all the associated problems : unable to add new feature without
    rewrite a very large proportion (all ?) of the code, no type safe,
    explosion of the number of SQL queries usually hardcoded, etc.

    - --
    Aeris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAgAGBQJOGYvvAAoJEK8zQvxDY4P9nHkH/3e6xujzVwXcXeEb6YZ4q8Rf
    dJmskyd+ZBF20Lf+DcQ7MPn0sQOsTGY4gPLn6adTPYTqJeHP8Nn9qDxLRwDuzZ3g
    4MF10cT2NTe2VZT7Sy0SPYViQNr+fiEJL5JAahPcYfY2RBK0bmfR6b7VcXPq6coa
    sUdlqDdVr2ML1hdi6ji/OM/3PHXYoHXtSHU0Bbnq60YbvYEk8J+4rLxVEqCOzlmb
    MRse1U4GiN6Ji6AsG+bVdDFmwPlJ6IytZJzeI5myFpApWhhrD3lOZteni7Ws1nsU
    91jFVCRv/2/p1CG+SNjj2SnXrAlsFT2FCsB2dtY0T06tW8DkDdGHn5Kw0lmPVsg=
    =uYF8
    -----END PGP SIGNATURE-----
    Aéris, Jul 10, 2011
    #5
  6. On 11-07-09 09:32 PM, Jack wrote:
    > On Jul 9, 4:01 pm, markspace <-@.> wrote:
    >> On 7/9/2011 2:56 PM, Jack wrote:
    >>
    >>> With spring and hibernate so popular now, is there anybody still only
    >>> use JDBC to write database application code? Thanks.

    >>
    >> I'm sure someone is, but yes I assume that JPA & Hibernate and
    >> dependency injection frameworks like Spring and JSF have become the norm.
    >>
    >> Still good to know what JDBC is and does, since it's used by JPA and
    >> Hibernate (et al.).

    >
    > Is using JDBC to access database more efficient than using
    > Spring/hibernate?


    Define "efficiency". Is it runtime efficiency - knowing that you've got
    the best possible SQL statement for actual load conditions - or is it
    development efficiency - producing adequate DB access code in an
    acceptable amount of team time?

    There are a number of considerations that come into play. A major one is
    the fact that only a minority of developers have sufficient SQL-fu and
    also specific RDBMS knowledge to do a better job of writing SQL than a
    JPA persistence provider like Hibernate or EclipseLink will. That's to
    say, one does not usually observe that standalone native SQL written by
    a given programmer is substantially better than the SQL generated from
    EJBQL which is written by the _same_ programmer.

    In fact, in a dev shop where coders are allowed too free rein to write
    native SQL in a JPA context, their SQL is often worse than if they had
    expressed their solution within the constraints of EJBQL. Unless they
    are top-notch people.

    With the latest JPA (version 2.x) there is also a type-safe criteria API
    that offers more benefits than what the accessors available on JDBC's
    ResultSet and PreparedStatement do. You can certainly do some typesafe
    queries with JDBC's DataSet but at this point you're simply edging into
    functionality that JPA takes for granted as basic.

    In deciding what approach to take, I myself would not worry about
    runtime performance excessively, at the gitgo, other than making sure
    that regardless of whether the DB access code is in SQL or EJBQL, that
    the coders are competent with the underlying fundamentals of accessing
    an RDBMS. A coder who is not competent here will write an abortion
    either way. To put it another way, the programmer should be capable of
    producing good SQL, no matter what, but given that they may in fact
    _then_ be better off writing EJBQL in a JPA environment.

    Assuming basic competency, you'll really only discover at testing time
    what DB accesses are not up to snuff in terms of performance. This would
    be true for either straight JDBC (possibly using something like MyBatis,
    though) or JPA with Hibernate or EclipseLink. At this stage of the game
    your programmers may well engage the help of a DBA for some fine-tuning.
    Much of the fine-tuning will have little to do with the actual SQL anyway.

    Myself I tend to go with JPA 2, and only those DB accesses that either
    cannot be fully expressed in EJBQL, and/or are complex enough that they
    are better off in a stored procedure, usually end up in hardcoded SQL
    someplace. Bear in mind that modern JPA persistence providers offer a
    lot of customization features for finetuning, so it's rare to encounter
    a _performance_ situation that forces you to use native SQL.

    One larger consideration is persistence management. It is _both_ a pro
    and a con of JPA that you place your persistent data, in the form of
    objects, under the management of the persistence provider. This is such
    a large topic that it's probably best the subject of another thread. But
    it's absolutely an important factor in deciding between JPA and straight
    JDBC.

    AHS
    Arved Sandstrom, Jul 10, 2011
    #6
  7. Jack

    Aéris Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Le 10/07/2011 02:32, Jack a écrit :
    > Is using JDBC to access database more efficient than using
    > Spring/hibernate?


    Usually, Hibernate is the very most efficient.

    Hibernate use 2 levels of cache to store query results and retrieved
    objects.
    For example, if you fetch one object, modify it 100×, and then delete
    it, Hibernate does only 2 requests : select and delete. All update are
    useless.
    An other example is retrieving the same object 100× generate only one
    select the first time, all others accesses using the Hibernate cache to
    find the object.

    But Hibernate could be very inefficient if your mapping is badly done.
    Lazy loading could collapse your database engine under thousands of
    short queries to fetch all children of one object.
    On the opposite, eager loading could fetch the ¾ of your database only
    with one query.

    Hibernate is more efficient if you use it correctly.

    - --
    Aeris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAgAGBQJOGY4dAAoJEK8zQvxDY4P9dhUH/2FfGAO1NoM1HUEoK8518b8R
    KOb4fXcEwE6L19SAOIrPWngbuhtdq1InO/we7sDogUfsqQJVyIGLT26hJ37e6Ppi
    V27IYabTMMC+GMaPAx3mK7JnHr26T6+UvlaoENdJ5zzV/1yCZZLuBglSrOg24nsg
    QiTd71rqMe7Vnjuaiurxr473vaVX3jASRoi0Y0lHvsBbX4cyognO3pxV/fzD0v+R
    9+MbbqE0JnReU99BP9s0vlrpJy2tioQzT0KP0pPJHwHQU8eBkyOsT7A54jxrxJRf
    L/5G6EoEQgLKLRVsT/mMKW8jowIyYDtX4wBxb/xGQtLxbDFGjhppCwYWAnby44Q=
    =puE0
    -----END PGP SIGNATURE-----
    Aéris, Jul 10, 2011
    #7
  8. Jack

    Elegie Guest

    On 10/07/2011 13:24, Aéris wrote :

    Hi,

    >> With spring and hibernate so popular now, is there anybody still only
    >> use JDBC to write database application code? Thanks.

    >
    > Unfortunately, yes…
    >
    > With all the associated problems : unable to add new feature without
    > rewrite a very large proportion (all ?) of the code, no type safe,
    > explosion of the number of SQL queries usually hardcoded, etc.


    You are right, but I believe you point at the wrong culprit. Is it the
    fault of JDBC if a programmer does not decouple his design, does not
    leverage design patterns, does not apply basic object-orientation
    principles (open-closed principle, single responsibility principle come
    to mind with the examples you have listed)?

    It is not so difficult to design an application, separating cleanly the
    different application layers, among which some data layer efficiently
    encapsulating data access.

    Frameworks are interesting because they somehow force good-enough
    designs upon programmers. The final product shall be of higher quality,
    but the programmer will not become any better (because he will
    experience even less about application designing).

    Regards,
    Elegie.
    Elegie, Jul 10, 2011
    #8
  9. Jack

    Aéris Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Le 10/07/2011 13:56, Elegie a écrit :
    > You are right, but I believe you point at the wrong culprit. Is it the
    > fault of JDBC if a programmer does not decouple his design, does not
    > leverage design patterns, does not apply basic object-orientation
    > principles (open-closed principle, single responsibility principle come
    > to mind with the examples you have listed)?


    Yes and no in same time.

    I agree with you, it is possible to write good code using JDBC, but this
    is a real pain because JDBC is not at all object-oriented, but
    data-oriented. Obtained architecture is a real mess, using tricks and
    bloated code one all levels.

    So, good code is possible but efficiency « real usefull functionnalities
    / time passed » tends to 0 with JDBC « good architecture », and
    discourages to do good things…

    - --
    Aeris
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iQEcBAEBAgAGBQJOGZhnAAoJEK8zQvxDY4P9ou8H/i6umYntQ4WK9qghfFqnZrRE
    kc8ajNUlEQwUUVJQ2oZdhOVhJJZ8w+hme70jxWfLCfnW7DQaPr/TpY/QI2VCdTCI
    6CGffpsFdOdirnkKohx/uMimeUvhF5bCWyOtXajoGKIC6oSABh0rfCO8UMEz7mrx
    ha75TN8c/OziBS2dOv2NH5PJRIoLYmLZRKGP8twpuEYnSs2HElTjtd4J5xidiqzw
    2CYsL31YOA+aGo+ff8Acr4Zmc341c4ScQ1iteZyTUWoGwh9gCEdx+sO7qfj9DhwY
    uV6+Ima6fihrHpG5DNeRaszlstDuNpL3Dy3JbhMbVwEtZfHJSzVBuwUzPNR+Ewg=
    =GLbi
    -----END PGP SIGNATURE-----
    Aéris, Jul 10, 2011
    #9
  10. Jack

    Stefan Ram Guest

    Jack <> writes:
    >With spring and hibernate so popular now, is there anybody still only
    >use JDBC to write database application code? Thanks.


    I like the idea of JPA, but AFAIK, no implementation is part
    of Java SE? So the canonical way to develope a desktop
    application with JPA would be to mix Java SE with a database
    and a JPA implementation?

    I dislike to depend on too many different libraries and
    providers (i.e., Java SE is provided by Oracle, Hibernate by
    another party, the database possibly by another party).

    I am disappointed that Derby is only part of the JDK, but
    not of the JRE. I surely would love Derby and an JPA
    implementation to be part of Java SE!
    Stefan Ram, Jul 10, 2011
    #10
  11. Jack

    Tom Anderson Guest

    On Sat, 9 Jul 2011, markspace wrote:

    > On 7/9/2011 2:56 PM, Jack wrote:
    >
    >> With spring and hibernate so popular now, is there anybody still only
    >> use JDBC to write database application code? Thanks.

    >
    > I'm sure someone is, but yes I assume that JPA & Hibernate and
    > dependency injection frameworks like Spring and JSF have become the
    > norm.


    This has also been my impression. On my current project, we do still write
    raw SQL using JDBC on occasion, but only because we need to do some sort
    of mad query that can't be done with our persistence provider. For
    instance, we have a query that runs every hour to update our list of
    top-selling products, which joins together all sorts of tables and inserts
    the result directly into a table. I don't think there's any way to do that
    (up to and including inserting from the select) with JPA.

    Now, having said that, it appears that somebody doesn't see raw JDBC as
    being limited to corner cases, because they've steadily been adding
    features to it. Features i find quite baffling. Here's what's coming in
    JDK 7 (skip over the try-with-resources stuff, which is great, but not
    baffling):

    http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html

    Who is the target market for this RowSetFactory stuff? In fact, who is the
    target market for the existing RowSets? We have CachedRowSet,
    FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of which
    i have ever seen used or advocated. Who is using these, and what for?

    The javadoc for JdbcRowSet says:

    A wrapper around a ResultSet object that makes it possible to use the
    result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
    one of the Beans that a tool makes available for composing an
    application.

    Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea
    dead in, like, 1998? What the hell is going on here? Is there some mad
    backwater Lost World of Java development where people are actually
    building apps by dragging icons around in tools?

    tom

    --
    Everyone has to die sooner or later, whether they be killed by germs,
    crushed by a collapsing house, or blown to smithereens by an atom bomb. --
    Mao Zedong
    Tom Anderson, Jul 10, 2011
    #11
  12. On 11-07-10 09:24 AM, Stefan Ram wrote:
    > Jack <> writes:
    >> With spring and hibernate so popular now, is there anybody still only
    >> use JDBC to write database application code? Thanks.

    >
    > I like the idea of JPA, but AFAIK, no implementation is part
    > of Java SE? So the canonical way to develope a desktop
    > application with JPA would be to mix Java SE with a database
    > and a JPA implementation?
    >
    > I dislike to depend on too many different libraries and
    > providers (i.e., Java SE is provided by Oracle, Hibernate by
    > another party, the database possibly by another party).


    FWIW, Stefan (and you likely know this), Oracle has EclipseLink as a JPA
    implementation. And it's the reference implementation as well.

    All that matters to me is that the Java Persistence API is in
    javax.persistence, and it's considered to be a framework for _both_ J2SE
    and J2EE/Java EE. That's standard enough for me. I in fact prefer that
    the actual implementation decision is not made for me by bundling.

    > I am disappointed that Derby is only part of the JDK, but
    > not of the JRE. I surely would love Derby and an JPA
    > implementation to be part of Java SE!
    >

    What do you gain? The persistence API is standard after all. And are you
    sure you'd want to have either Hibernate or OpenJPA or EclipseLink
    (among others) hardwired into the J2SE distro? If Hibernate, for
    example, were included, *I* wouldn't be all that happy, but many others
    would be pleased. If EclipseLink were bundled, I'd be happy, but others
    would be displeased. I see no win-win here.

    It's exceptionally easy to include any of the common JPA implementations.

    AHS
    Arved Sandstrom, Jul 10, 2011
    #12
  13. On 11-07-10 09:34 AM, Tom Anderson wrote:
    > On Sat, 9 Jul 2011, markspace wrote:
    >
    >> On 7/9/2011 2:56 PM, Jack wrote:
    >>
    >>> With spring and hibernate so popular now, is there anybody still only
    >>> use JDBC to write database application code? Thanks.

    >>
    >> I'm sure someone is, but yes I assume that JPA & Hibernate and
    >> dependency injection frameworks like Spring and JSF have become the norm.

    >
    > This has also been my impression. On my current project, we do still
    > write raw SQL using JDBC on occasion, but only because we need to do
    > some sort of mad query that can't be done with our persistence provider.
    > For instance, we have a query that runs every hour to update our list of
    > top-selling products, which joins together all sorts of tables and
    > inserts the result directly into a table. I don't think there's any way
    > to do that (up to and including inserting from the select) with JPA.


    Short of using features that are peculiar to an implementation, it seems
    to me that if you had that result table described as a JPA entity, you
    could use an EJBQL constructor expression to load up the to-be-inserted
    entities from that mess of joins. Persist _those_.

    Just a thought. In real life I'd probably write the guts as a stored
    proc, and have it run with a DB scheduler like Oracle Scheduler.

    > Now, having said that, it appears that somebody doesn't see raw JDBC as
    > being limited to corner cases, because they've steadily been adding
    > features to it. Features i find quite baffling. Here's what's coming in
    > JDK 7 (skip over the try-with-resources stuff, which is great, but not
    > baffling):
    >
    > http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html
    >
    > Who is the target market for this RowSetFactory stuff? In fact, who is
    > the target market for the existing RowSets? We have CachedRowSet,
    > FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of
    > which i have ever seen used or advocated. Who is using these, and what for?
    >
    > The javadoc for JdbcRowSet says:
    >
    > A wrapper around a ResultSet object that makes it possible to use the
    > result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
    > one of the Beans that a tool makes available for composing an
    > application.
    >
    > Waitwhat? Tools composing applications out of JavaBeans? Wasn't that
    > idea dead in, like, 1998? What the hell is going on here? Is there some
    > mad backwater Lost World of Java development where people are actually
    > building apps by dragging icons around in tools?
    >
    > tom
    >

    Seems like VisualStudio envy to me. And way behind the curve at that.

    AHS
    Arved Sandstrom, Jul 10, 2011
    #13
  14. Sun, 10 Jul 2011 11:08:01 -0300, /Arved Sandstrom/:
    > On 11-07-10 09:34 AM, Tom Anderson wrote:
    >
    >> This has also been my impression. On my current project, we do still
    >> write raw SQL using JDBC on occasion, but only because we need to do
    >> some sort of mad query that can't be done with our persistence provider.
    >> For instance, we have a query that runs every hour to update our list of
    >> top-selling products, which joins together all sorts of tables and
    >> inserts the result directly into a table. I don't think there's any way
    >> to do that (up to and including inserting from the select) with JPA.

    >
    > Short of using features that are peculiar to an implementation, it seems
    > to me that if you had that result table described as a JPA entity, you
    > could use an EJBQL constructor expression to load up the to-be-inserted
    > entities from that mess of joins. Persist _those_.


    I was just about to ask whether one have used such Constructor
    Expressions in real life:

    http://download.oracle.com/javaee/5/tutorial/doc/bnbuf.html#bnbwc
    http://download.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc

    --
    Stanimir
    Stanimir Stamenkov, Jul 10, 2011
    #14
  15. On 11-07-10 11:45 AM, Stanimir Stamenkov wrote:
    > Sun, 10 Jul 2011 11:08:01 -0300, /Arved Sandstrom/:
    >> On 11-07-10 09:34 AM, Tom Anderson wrote:
    >>
    >>> This has also been my impression. On my current project, we do still
    >>> write raw SQL using JDBC on occasion, but only because we need to do
    >>> some sort of mad query that can't be done with our persistence provider.
    >>> For instance, we have a query that runs every hour to update our list of
    >>> top-selling products, which joins together all sorts of tables and
    >>> inserts the result directly into a table. I don't think there's any way
    >>> to do that (up to and including inserting from the select) with JPA.

    >>
    >> Short of using features that are peculiar to an implementation, it seems
    >> to me that if you had that result table described as a JPA entity, you
    >> could use an EJBQL constructor expression to load up the to-be-inserted
    >> entities from that mess of joins. Persist _those_.

    >
    > I was just about to ask whether one have used such Constructor
    > Expressions in real life:
    >
    > http://download.oracle.com/javaee/5/tutorial/doc/bnbuf.html#bnbwc
    > http://download.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc
    >

    I have used them fairly frequently to prepare presentation models in
    JSF, to use Martin Fowler's terminology. This is related also to view
    models in Microsoft WPF.

    To give an example, if a JSF dataTable has numerous columns, and quite a
    few of them are fields of _many_ entities that are all retrieved by a
    complex query with joins, it can be quite convenient to use a JPQL ctor
    expression to load up a List of presentation model class instances. This
    is more concise, and it more clearly keeps a division between
    persistence and view backing data.

    HTH,
    AHS
    Arved Sandstrom, Jul 10, 2011
    #15
  16. Jack

    Tom Guest

    On Sat, 09 Jul 2011 16:01:24 -0700, markspace wrote:

    > On 7/9/2011 2:56 PM, Jack wrote:
    >> With spring and hibernate so popular now, is there anybody still only
    >> use JDBC to write database application code? Thanks.

    >
    >
    > I'm sure someone is, but yes I assume that JPA & Hibernate and
    > dependency injection frameworks like Spring and JSF have become the
    > norm.
    >
    > Still good to know what JDBC is and does, since it's used by JPA and
    > Hibernate (et al.).


    Slightly off-topic I know but I gave up welding databases and class
    designs together. Libraries with complex semantics and using xml to wire
    up your application. Ugh.

    Theory is here: http://www.inqwell.com/reify1.pdf

    Regarding database access, practice is here:
    http://www.inqwell.com/primer/keys.html#keytypes
    Tom, Jul 10, 2011
    #16
  17. Jack <> writes:

    > With spring and hibernate so popular now, is there anybody still only
    > use JDBC to write database application code? Thanks.


    Yes.
    I'm maintaining a large application that has all the database access
    done with jdbc, mainly for historical reasons.

    The application has been in production since the beginning of 2004, and
    at some early point of the implementation project (about 2001 or 2002)
    people experienced some problems with entity beans not always being
    saved to the database in the correct order (or something like that, it
    was before I got involved) and decided to switch to raw jdbc.

    That was the days of Java 1.3 and ejb 2.1. If the application were to be
    rewritten today, we would probably use hibernate or something.

    --
    Jukka Lahtinen
    Jukka Lahtinen, Jul 11, 2011
    #17
  18. Hi!

    markspace wrote:

    > Still good to know what JDBC is and does, since it's used by JPA and
    > Hibernate (et al.).


    If you want to create complex database centered applications and
    want decent security you would create an API in the database
    without any direct access to tables for the application.

    Very often you have different applications running the same
    type of tasks even based on different programming languages.

    Just imagine a hotel reservation system (single property).
    You have the following apps creating/updating reservations:

    1. The local property management system
    2. The chain's central reservation system
    3-10. 3rd party reservation systems (for travel agent reservations)
    11. Hotel's web site
    12. Chain's web site
    13-20. Other web sites doing reservations for you.

    If you use a capable DB (such as Oracle) you do everything via
    packaged stored procedures and (pipelined or not) table functions.
    You cannot trust any outside application, so do the same for
    your own stuff.

    This approach additionally prevents any SQL injection.

    In this case Hibernate is pretty useless (just an additional layer
    of framework heavily using reflections making debugging more
    complicated than necessary.

    Gunter in Orlando, Florida

    --
    I know SQL and PL/SQL.
    I don't have to hibernate
    Gunter Herrmann, Jul 11, 2011
    #18
  19. Jack

    lewbloch Guest

    On Jul 9, 5:32 pm, Jack <> wrote:
    > On Jul 9, 4:01 pm, markspace <-@.> wrote:
    >
    > > On 7/9/2011 2:56 PM, Jack wrote:

    >
    > > > With spring and hibernate so popular now, is there anybody still only
    > > > use JDBC to write database application code? Thanks.

    >
    > > I'm sure someone is, but yes I assume that JPA & Hibernate and
    > > dependency injection frameworks like Spring and JSF have become the norm.

    >
    > > Still good to know what JDBC is and does, since it's used by JPA and
    > > Hibernate (et al.).

    >
    > Is using JDBC to access database more efficient than using
    > Spring/hibernate?


    Yes and no. It can be more efficient as a programmer to use Hibernate
    (but don't use Spring!), at least if you stay with the JPA-compliant
    parts of Hibernate. It can run more efficiently to use JDBC without
    JPA, but usually is not.

    Unfortunately, most use of Hibernate in the wild is quite ignorant and
    harms the respective projects. I have yet to encounter intelligent
    use of Spring in a real project.

    Good use of JPA will make your program quite clean and maintainable,
    i.e., very efficient in the development and maintenance dimensions.
    Bad use of JPA, like bad use of a chain saw, results in a horror-movie
    scenario. For certain bulk operations, JDBC is better.

    Asking about "efficiency" for use of JPA vs. JDBC calls is like asking
    if it's more efficient to use an automobile than a bicycle. The use
    cases differ, so where one is more appropriate the other is less so,
    and "efficiency" has little to nothing to do with it. That is to say,
    "efficiency with respect to what?" is your real question.

    So, efficiency with respect to what?

    Use JPA when you want to code to an object model that persists itself,
    without regard for the data-centric point of view. Use JDBC when you
    need a relational model of your persistent data.

    Eschew Spring.

    --
    Lew
    lewbloch, Jul 11, 2011
    #19
  20. Jack

    lewbloch Guest

    On Jul 10, 5:24 am, -berlin.de (Stefan Ram) wrote:
    > Jack <> writes:
    > >With spring and hibernate so popular now, is there anybody still only
    > >use JDBC to write database application code? Thanks.

    >
    >   I like the idea of JPA, but AFAIK, no implementation is part
    >   of Java SE? So the canonical way to develope a desktop
    >   application with JPA would be to mix Java SE with a database
    >   and a JPA implementation?
    >
    >   I dislike to depend on too many different libraries and
    >   providers (i.e., Java SE is provided by Oracle, Hibernate by
    >   another party, the database possibly by another party).
    >
    >   I am disappointed that Derby is only part of the JDK, but
    >   not of the JRE. I surely would love Derby and an JPA
    >   implementation to be part of Java SE!


    JPA is a standard, and all implementations work with Java SE.

    Derby is free to distribute and not always needed in every JRE
    installation, so why include it for the grand majority of users who
    don't need it? If it's needed, the app will include the JAR, since
    every Java developer will use the JDK and therefore will have Derby.
    That suffices.

    One advantage of the current distribution strategy is that the
    developer can choose the DB and JPA providers. Another is that the
    user only gets the libs needed for their apps.

    That the SE comes from wherever (Oracle, IBM, another party), the
    database from wherever (Derby, Postgres), and the JPA from a third
    (Oracle, Apache), is not a detriment but an asset. It's called
    choice. Learn to like it.

    --
    Lew
    lewbloch, Jul 11, 2011
    #20
    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. Rhino
    Replies:
    2
    Views:
    6,158
    James McGill
    Feb 24, 2006
  2. Marc E
    Replies:
    0
    Views:
    1,478
    Marc E
    Jun 25, 2006
  3. rmn190
    Replies:
    2
    Views:
    2,339
    Arne Vajhøj
    Jan 10, 2008
  4. Goldfish
    Replies:
    1
    Views:
    657
    Goldfish
    Nov 6, 2008
  5. Amit Jain
    Replies:
    7
    Views:
    3,271
    Amit Jain
    Apr 27, 2009
Loading...

Share This Page