The majority of applications need to persist (or store) data during their lifecycle. There are many ways of doing this with an application written in Java.

    • If your datastore is RDBMS you can handle the persistence (and retrieval) of data yourself using JDBC. Obviously with this route you have the burden of having to write the persistence layer yourself. This gives much control, but also creates significant work, both in writing the code but also in testing and maintenance.
    • You can use JDO, a standardised persistence API. With JDO you can develop plain old java objects (POJOs) and persist them as they are transparently. This requires very little work from the developer. It allows persistence to any type of datastore in principle, being designed with flexibility and datastore agnositicity in mind. This has been a standard since 2002 (JDO1), being upgraded in 2006 (JDO2) and is in the process of being developed further (JDO2.1) by Apache JDO
    • You can use JPA, a standardised persistence API, and part of the EJB3 specification. This also allows you to to develop plain old Java objects (POJOs) and persist them using a standardised API. It’s specification is not as mature or as feature rich as the JDO API, nor does it provide the flexibility of using any type of datastore. This was released in 2006 (JPA1) to supercede EJB2. It really only allows persistence to RDBMS datastores. If you want to persist to other datastores you should consider JDO.
    • If you are stuck with using an EJB2.* architecture you could use Entity Beans. This means that you hand off your objects to the EJB part of the J2EE server. This simplifies things for the developer in some respect but places major restrictions in that your objects have to be Entity Beans.
    • You can also use a proprietary persistence API (e.g Hibernates own API, TopLinks own API, iBatis, Castor etc). The disadvantages of going this route are that you cannot easily swap to an alternative implementation of the API if you hit problems with your software choice.

    To give a guide, here are a few important consideration points when choosing a persistence layer for your application.

    Feature JDBC JDO JPA EJB2 Custom ORM
    Standards-Driven Image 1: image Image 2: image Image 3: image Image 4: image Image 5: image
    Choice of datastores Image 6: image Image 7: image Image 8: image Image 9: image Image 10: image
    Support POJOs Image 11: image Image 12: image Image 13: image Image 14: image Image 15: image
    Usable in J2SE Image 16: image Image 17: image Image 18: image Image 19: image Image 20: image
    Usable in J2EE Image 21: image Image 22: image Image 23: image Image 24: image Image 25: image
    Out of box implementation (1) Image 26: image Image 27: image Image 28: image Image 29: image Image 30: image
    Simple to unit test Image 31: image Image 32: image Image 33: image Image 34: image Image 35: image
    Dynamic queries Image 36: image (2) Image 37: image Image 38: image Image 39: image Image 40: image
    Comprehensive ORM Image 41: image Image 42: image Image 43: image Image 44: image Image 45: image
    Primary Key generation Image 46: image (2) Image 47: image Image 48: image Image 49: image Image 50: image
    Supports inherited objects Image 51: image (2) Image 52: image Image 53: image Image 54: image Image 55: image
    Schema Creation Image 56: image Image 57: image Image 58: image Image 59: image Image 60: image
    Existing schema Image 61: image Image 62: image Image 63: image Image 64: image Image 65: image
    1. refers to whether it is necessary to write the persistence yourself (e.g as with JDBC) or whether you can just persist by simple calls.
    2. requires the developer to write this layer.