Entity Beans and transparent persistence


EJB programming & troubleshooting: Entity Beans and transparent persistence

  1. Entity Beans and transparent persistence (2 messages)

    I know, that Entity Beans supports persistence.
    I have a question:
    Does Entity Beans support transparent persistence ?

  2. In some ways a very tricky question.

    I suppose it depends on if you really mean "transparent" or if you mean opaque ;-) Generally, I would consider transparent persistence to mean pure Java objects modeling some domain who's interaction with the database is not apparent in the .java representation of the model. This means that you do not have an external JDBC/SQL layer nor a bunch of other classes handling the interactions between the objects to manage relationships.

    Really, only JDO provides an implementation of the kind fitting the definition described above. You can find this in a growing number of places. Versant enJin, Solarmetic Kodo, Poet FastObject, Libelis, etc ... I suggest you see www.JDOcentral.com

    IMHO - Truly transparent persistence is where you do not consider the data representation separately from the in memory model. Even some of the JDO vendors still require you to take a backwards up approach to the transparent persistence. Starting with the data representation in the database and then working backwards towards your domain model, much like what is done within the IDE database integration tools for CMP. In many cases this is just unavoidable if you desire to get any kind of a performing application. Honestly, I am not sure if JDO will be much better performance and scalability wise then Entity Beans because when you get right down to it there is still a bunch of mapping code getting generated.

    As a developer, I would much rather focus on my business problem domain than ....how do I get this stuff into a database and still perform. So, I recommend Versant enJin because their process takes a JDO appraoch to persistence where there is no difference between the in memeory model and the model stored in the underlying database. This enables you to take a top down approach an focus on the real problem at hand.

    I work there too so I am biased, but I've tried many other ways to build these systems over the last 15 years and have not found any better way.


  3. You might want to check out "BLiF". I haven't found a faster way of getting a relation EJB schema up and running.

    It simply lets you to create a BMP schema to represent relational entities. Simply specify in XML each attribute to column mapping property (or create your own very simply) declare the associations between one EJB and another (cardinality, privacy role name etc). One neat feature allows you to declare object deletion hierariches ie what associated enties are deleted or dissassociated from when an object is remove()d. Run the XML through the code generator and you have the DDL to create your database, ejb-jar.xml plus all your BMP code ready to compile and deploy.

    It's not Toplink but it's unbelievably cheap!