Has JPA Killed the DAO?
- Share
-
- |
Read later
My Reading List
Recently there has been some discussion as to whether or not the Java Persistence API (JPA) has killed the Data Access Object (DAO). JPA (Java Persistence API) defines an interface to persist normal Java objects (or POJO's in some peoples terminology) to a datastore. Essentially this provides object-relational mapping similar to Hibernate and others. On the other hand, a DAO can be summed up as,
A Data Access Object (DAO) is a software component that provides a common interface between the application and one or more data storage devices, such as a database or file.
As with most discussions of this nature, bloggers from both sides have taken their stance. On one side, which initiated this discussion, Adam Bien states,
...The usage cannot be simpler. The EntityManager will be just injected to the bean-class...The DAO pattern is actually no more interesting for general data access, but is still needed to access data from stored procedures, flat files etc...Days later, magle argued that the DAO wasn't going anywhere,
there were some statements and blog posts about the end of the DAO pattern in the last weeks, especially in conjunction with the rising of EJB 3 and it's EntityManager. those proposals suggest to use EntityManager directly inside your business oriented services instead of encapsulating data access logic through a DAO. i strongly disagree with this opinion...Magle goes on to explain himself through the rest of the article by highlighting on various key issues:
- Mixing business logic with data access logic
- Violation of single responsibility principle
- Mixing business logic and infrastructure
- Violation of open closed principle
- lacks uniform style of data access strategies
The DAO-Pattern can be considered as a "Data Service Layer", which encapsulates the particular and often proprietary data access realization. The main purpose of such a layer would be to make your independent of the particular database or OR-mapper. But even in the past I never replaced the database or even switched from SQL to LDAP.
There are some cases, like e.g. encapsulation of legacy systems, were layers are mandatory. DAOs in my opinion can be highly optimized in Java EE 5 (until it disappears :-)). The DAO-Interface, implementation and Factory and the actual Session Bean can be collapsed. Of course we could argue, that it isn't very good to be dependent on EJB 3 - but why not? Just because of @Stateless annotation?
On each post there are numerous comments which continue the discussion, such as WarpedJavaGuy:
DAO's will not die any time soon. Persistence and data access are not one and the same.On the other hand, Antonio Goncalves replies:
Java EE has suffered of so much boiler plate code, design patterns that turned into anti-patterns, complexity and so on, that I have no problem in using EntitManager CRUD operations on my EJBs. For simple application, I skip the DAO pattern...
All in all the general consensus is that it all depends on the application and requirements. Adam sums it up,
I would say: it depends. It depends how complex your application really is.
Needs Criteria API
by
Jacob Hookom
The problem is that the JPA does not include the Criteria API as of yet.
DAOs will be around for a little while yet
by
Billy Newport
Re: DAOs will be around for a little while yet
by
Mohamed Ibrahim
Re: DAOs will be around for a little while yet
by
Steven Devijver
On the other hand the DAO pattern is crucial for layering. However, no two applications are the same and especially due to it's leakage of concerns DAOs may be redundant.
A far more interesting question (for me): is the DAO pattern crucial for good software quality? I still haven't figured that one out.
Re: DAOs will be around for a little while yet
by
Christian Schneider
Re: DAOs will be around for a little while yet
by
Handerson Gomes
Using the example above, without Christian permission, the method getCustomersWithCreditLimitLargerThan doesn't necessarily have to be in a DAO interface in order to be reused. A business object CustomerManager would expose this method along others which might not be related with a persistence layer but related with Customer Management (save, delete, getCustomersWhoBoughtItem(Item item), etc).
I would not design a CustomerBean with methods like save, delete and query methods, most because of "cleanness" and aesthetic: Having all those JPA queries inside the POJO does look awful and defy the purpose of Plain Old Object.
My understanding of what Adam's suggest is to have the persistence code inside a CustomerMgrBean instead of having it on a DAO layer or the CustomerBean itself.
Regards,
Handerson Gomes
DAOs are not a layer
by
Alexandre Poitras
I personally think the DAO patterns is outdated and we should move to the Repository pattern as introduced in the book "Domain Driven Design" instead. Implementation of this pattern aren't very different from the DAO pattern ones but at least it focus more on semantic issues rather then technical ones. The obvious advantages of this pattern aren't being able to switch the persistence mechanism but the abstraction and the coherence it brings to your domain model. I don't think the DAO pattern is outdated but we should switch to the cleaner Repository pattern instead.
Re: DAOs will be around for a little while yet
by
Christian Schneider
A business object CustomerManager would expose this method along others which might not be related with a persistence layer but related with Customer Management (save, delete, getCustomersWhoBoughtItem(Item item), etc).
This is exactly the purpose of a Repository class: Handling Persistence and Multitudes of certain objects. As these operations don´t fit into the simple domain classes it makes sense to factor them out to special classes that handle these parts of the domain model. Still I think it makes sense to only keep the interface of the Repository (or Manager like you call it) in the domain layer. So you can separate the implementation and can swap it for a dummy implementation if you want to do unit tests without a container and db access.
Re: DAOs are not a layer
by
Daniel Gredler
First of all, DAOs can't be a layer since they have a dependency on business objects.And your facades aren't a layer because they have a dependency on DTOs?
I personally think the DAO patterns is outdated and we should move to the Repository pattern as introduced in the book "Domain Driven Design" instead... *snip* I don't think the DAO pattern is outdated but we should switch to the cleaner Repository pattern instead.So... DAOs are outdated... but then you convince yourself that they aren't outdated?
Color me confused!
Re: DAOs are not a layer
by
Steven Devijver
First of all, DAOs can't be a layer since they have a dependency on business objects.And your facades aren't a layer because they have a dependency on DTOs?
DAOs are definitely a layer. Their arrangement package-wise is irrelevant.
Re: DAOs are not a layer
by
Alexandre Poitras
First of all, DAOs can't be a layer since they have a dependency on business objects.And your facades aren't a layer because they have a dependency on DTOs?I personally think the DAO patterns is outdated and we should move to the Repository pattern as introduced in the book "Domain Driven Design" instead... *snip* I don't think the DAO pattern is outdated but we should switch to the cleaner Repository pattern instead.So... DAOs are outdated... but then you convince yourself that they aren't outdated?
Color me confused!
LOL the joy of copy and paste and of a long day of work! I forgot to delete the last sentence. What I meant is that DAO still have a meaning but the pattern name and description are outdated.
Just to reiterate my point, DAOs are not a layer because one of the first law of the layer architectural pattern is that a lower layer is not allowed to have any dependencies on a upper layer. DAOs (or Repositories) have depencendies on your businness objects and therefore are a subpackage of the business layer. This is exactly why Repository is much cleaner than DAOs. It focus a lot more on the business aspects of the problems instead of the technical ones.
*I don't use DTOs anymore but they are part of the businness layer as a facade is.
Re: DAOs are not a layer
by
Steven Devijver
Just to reiterate my point, DAOs are not a layer because one of the first law of the layer architectural pattern is that a lower layer is not allowed to have any dependencies on a upper layer. DAOs (or Repositories) have depencendies on your businness objects and therefore are a subpackage of the business layer.
Who says "business objects" belong in the business layer, especially when they are mapped by a OR mapper? They might just as well belong to the data access layer.
Re: DAOs are not a layer
by
Alexandre Poitras
Just to reiterate my point, DAOs are not a layer because one of the first law of the layer architectural pattern is that a lower layer is not allowed to have any dependencies on a upper layer. DAOs (or Repositories) have depencendies on your businness objects and therefore are a subpackage of the business layer.
Who says "business objects" belong in the business layer, especially when they are mapped by a OR mapper? They might just as well belong to the data access layer.
Well because the OR mapper have no hard dependency on your business objects in a so conceptually according to the layer pattern, those are two independants layers. Of course, there is nothing disallowing you from merging the two bottom layers in your model if you want but I don't see why you would do that.
JPA has not killed the DAO
by
WarpedJavaGuy ;
The post suggests that you can remove the need for DAO's by bridging aggregate level Repository abstractions to ORM Repository implementations. Strictly defined root aggregates and powerful ORM's can make it possible. It is a very indirect approach and it does require more work. Whether or not we embrace the approach and evolve it could depend on how well we adopt DDD. Either way, JPA has not killed the DAO. ORM's have been around for a while and we still write DAO's today. But that might change if (dare I say it) DDD kills the DAO!
Re: DAOs are not a layer
by
Steven Devijver
Just to reiterate my point, DAOs are not a layer because one of the first law of the layer architectural pattern is that a lower layer is not allowed to have any dependencies on a upper layer. DAOs (or Repositories) have depencendies on your businness objects and therefore are a subpackage of the business layer.
Who says "business objects" belong in the business layer, especially when they are mapped by a OR mapper? They might just as well belong to the data access layer.
Well because the OR mapper have no hard dependency on your business objects in a so conceptually according to the layer pattern, those are two independants layers.
Try loading your OR mapper without the "business objects" classes in your classpath. There is no static dependency but a dependency nonetheless.
Classes that are mapped by an OR mapper - according to your layering theory - belong to the data access layer. The DAO/Repository/what-not can be a separate layer or part of the data access layer.
And in the end it doesn't really matter. Databases and OR mappers are so leaky that you can't properly abstract them anyway.
Re: DAOs are not a layer
by
Daniel Gredler
LOL the joy of copy and paste and of a long day of work!And not enough coffee? ;-)
Separation of concerns?
by
Luis Fernando Planella Gonzalez
For example: on the project I work, we have an advertisement, which may be permanent or have a publication period. But we search by status, let's say active. Who should know what defines an active advertisement? The business layer, of course. But we must put that code on a HQL query, because we need to find advertisements by status.
So, we DO NOT have separation of concerns here, because we also has a method isActive(ad) on the service layer...
My opinion: bash the DAO layer.
Re: DAOs are not a layer
by
Dimitris Menounos
I searched for a visual representation and this is the closest I could find.
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think