Monday, December 8, 2008

Reason to choose Hibernate for Floreant POS





Florant POS is based on Hibernate, an Object-Relational Mapping (ORM) solution for JAVA. It is a powerful, high performance object/relational persistence and query service. It allows us to develop persistent classes following object-oriented idiom – including association, inheritance and polymorphism.

From the day one we focused on quality and flexibility of code. . Here is a clearcut comparison between Hibernate and JDBC that supports reasons to choose hibernate. Source: Java sample




JDBC vs Hibernate

  1. Mapping Java class to tables
    With JDBC, developer has to write code to map an
    object model's data representation to a relational data model and its
    corresponding database schema.

    Hibernate is flexible and powerful ORM solution to
    map Java classes to database tables. Hibernate itself takes care of this
    mapping using XML files so developer does not need to write code for
    this.

  2. Persistence of code
    With JDBC, the automatic mapping of Java objects
    with database tables and vice versa conversion is to be taken care of by
    the developer manually with lines of code.

    Hibernate provides transparent persistence and
    developer does not need to write code explicitly to map database tables
    tuples to application objects during interaction with RDBMS.

  3. SQL & More
    JDBC supports only native Structured Query
    Language (SQL). Developer has to find out the efficient way to access
    database, i.e. to select effective query from a number of queries to
    perform same task.

    Hibernate provides a powerful query language
    Hibernate Query Language (independent from type of database) that is
    expressed in a familiar SQL like syntax and includes full support for
    polymorphic queries. Hibernate also supports native SQL statements. It
    also selects an effective way to perform a database manipulation task for
    an application.

  4. Less coding in XML Mapping
    Application using JDBC to handle persistent data
    (database tables) having database specific code in large amount. The code
    written to map table data to application objects and vice versa is
    actually to map table fields to object properties. As table changed or
    database changed then it’s essential to change object structure as well as
    to change code written to map table-to-object/object-to-table.

    Hibernate provides this mapping itself. The actual
    mapping between tables and application objects is done in XML files. If
    there is change in Database or in any table then the only need to change
    XML file properties.

  5. Generation of Java Object
    With JDBC, it is developer’s responsibility to
    handle JDBC result set and convert it to Java objects through code to use
    this persistent data in application. So with JDBC, mapping between Java
    objects and database tables is done manually.

    Hibernate reduces lines of code by maintaining
    object-table mapping itself and returns result to application in form of
    Java objects. It relieves programmer from manual handling of persistent
    data, hence reducing the development time and maintenance cost.



  6. Database caching
    With JDBC, caching is maintained by hand-coding.

    Hibernate, with Transparent Persistence, cache is
    set to application work space. Relational tuples are moved to this cache
    as a result of query. It improves performance if client application reads
    same data many times for same write. Automatic Transparent Persistence
    allows the developer to concentrate more on business logic rather than
    this application code.

  7. Database update checking
    In JDBC there is no check that always every user
    has updated data. This check has to be added by the developer.

    Hibernate enables developer to define version type
    field to application, due to this defined field Hibernate updates version
    field of database table every time relational tuple is updated in form of
    Java class object to that table. So if two users retrieve same tuple and
    then modify it and one user save this modified tuple to database, version
    is automatically updated for this tuple by Hibernate. When other user
    tries to save updated tuple to database then it does not allow saving it
    because this user does not have updated data.