ORM and the misleading DAO pattern


General J2EE: ORM and the misleading DAO pattern

  1. ORM and the misleading DAO pattern (3 messages)

    The DAO layer offers a great enhancement in the process of software development. It effectively decouples the business layer from the persistence mechanism. For this reason it gives robustness to our application's architecture and flexibility when it comes to the unavoidable evolutions and branches of our work. In fact changing the way data is persisted (e.g. JDBC - possibly between different vendors, XML, File) is simply a matter of writing new DAO implementations in a well isolated layer. But with the introduction of an ORM, well, thing changes quite a lot. Imagine the following scenario: we've got an application developed with a well isolated DAO layer that interacts with a database via JDBC. Now we want to switch to an ORM solution (e.g. Hibernate) by writing a new DAO implementation which makes calls to our ORM. Sounds good ... bat, wait ... how about the way the business and the view layers are handling the domain objects? There is nothing in these layers to prevent developer from changing a domain object just loaded by the DAO layer. With a JDBC-oriented DAO in mind the developer is free to change anything about a loaded object, maybe for view reasons or for in-memory elaborations. As far as the object is not explicitly updated through calling the DAO again, one thinks the object to be just an in-memory (transient) copy of the original persisted one. This is not the case when using an ORM approach! Switching to an ORM (often) implies that the object loaded and passed to the business and view layers is persistent; so any change to its properties, any change to relations with other objects will be automatically made persistent, no matter if the DAO is called again. On the other hand switching from an ORM-oriented to a JDBC-oriented DAO (or XML, file) will soon fail because of the missing DAO update calls that an ORM approach does not require. In conclusion the DAO pattern does not isolate well; business and view layers must know if they are handling persistent (automatically updated) or transient (updated upon an explicit request) domain object. Some suggest never to expose directly the persistent object, but a transient copy of them (through another set of classes or by detaching objects). Sorry, but I prefer to deal with a poorly isolated DAO layer (thus giving away with the JDBC-ORM switching option) than giving away with the advantages of handling persistent objects directly. I mean, all the overhead working needed to detach/reattach objects or to copy properties back and forth between persistent and transient object almost kills the ORM choice. Better to have a full ORM with a half DAO than a swichable DAO with a half ORM, IMHO. Do we have to split the DAO pattern in two in order to have a clearer distinction? Or am I missing something? I'd appreciate your opinions. References 1) Rationale of using DAO layer with ORM solution https://www.theserverside.com/discussions/thread.tss?thread_id=36319 2) Of Persistence and POJOs: Bridging the Object and Relational Worlds http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk9.html Vincenzo Caselli email: info at censnet dot it www: www.censnet.it
  2. I don´t fully agree[ Go to top ]

    I don't think that the problem here is the pattern in itself, but the implementation of the pattern. It's clear that changing an ORM DAO implementation with a typical JDBC implementation will not work correctly. Furthermore, the exceptional performance improvement of using lazy initialization will not be present in the JDBC version. The thing here is that the JDBC implementation should work correctly if it is well implemented. This means that, for example, AOP techniques should be used to do lazy initialization and an Observer Pattern can be used to have the same functionality of an ORM in "automatic" updates. I do agree in the refusal of using ORM without those things that make the traditional JDBC approach because it wouldn't take advantage of these important features.
  3. I think the problem is more where you call the DAO : in service objet or/and in the domain objects. I know lot of people disagree but I think that lot of times it makes more sence to call the DAO straight in your domains objects. Anyway, most ORM DAO are pretty simple. They convert the exception into generic exception and plug in the ORM transaction implementation.
  4. I do agree, and also what about the reverse problem. Suppose I wrote a perfect loosely coupled DAO, that returns to my business methods model objects. If I first wrote the DAO with an ORM I will have a persistent object and all my work will be automatically updated on the relational DB. If then I switch to a JDBC based DAO I will loose this, and only with the use of AOP I will be guaranteed that the model will be correctly updated. So in my opinion the only use-case for a completely switchable (between ORM and plain JDBC or iBatis) DAO pattern is with read-only model objects.