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, files) is simply a matter of writing new DAO implementations in a well isolated layer.
But with the introduction of an ORM, well, things change 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 ... but wait! How about the way the business and the view layers are handling the domain objects? There is nothing in these layers to prevent developers 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). However, 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:
No comments:
Post a Comment