Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Craig Wickesser on Sep 16, 2007
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:
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.
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
The 5 Mandates of Software Development Teams - Presto Manifesto
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Tightly encapsulated DAOs can produce maintenance difficulties with managing optimal use cases. Fetching data optimally for all cases sometimes requires unconventional approaches to the DAO pattern where we've found the Criteria API from HB meets that. Your DAO maintains two methods, queryXXX and listXXX, allowing you to setup your biz assertions to produce a Criteria instance and then have the listXXX method just eval the Criteria returned by the queryXXX equivalent. By returning Criteria objects, you can still preserve the 'what', but allow web-actions to assert appropriate projections and fetch sizes based on optimal use cases much higher in the application stack.
The problem is that the JPA does not include the Criteria API as of yet.
I don't think the DAO is dead yet. A JPA graph is still pretty much directly tied to the schema of the underlying data source. A DAO can potentially be decoupled from that schema and might represent a denormalized view or something like that. I can see such high level DAOs being implemented using code that makes use of JPA. A DAO is a higher level construct, not so tightly coupled with the underlying schema as JPA entities will be.
You're right, the DAO won't die soon. But I think denormalization shouldn't be its job, you can create normalized views if you interfacing with a legacy/third party system or normalize your own schema to make it JPA/DAO friendly.
I believe claim for or against the DAO pattern don't stick. First of all, DAO is one of the most problematic abstractions because of it's leakage of concerns, especially but not only with OR mappers. You can't simply ignore this when considering the merits of the DAO pattern.
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.
In my opinion the reason why to have a DAO layer is to encapsulate database code and give the access function a name that plays a role in your domain model. So for example you could have a dao method like CustomerRepository.getCustomersWithCreditLimitLargerThan(Bigdecimal amount). This explains your intent much better than a JPA query. The art is then to make these expressive statements reusable and still focused on the domain task. Eric Evans talks about this a lot in Domain Driven Design though he does not really mention DAO. Perhaps the DAO code will simply be put in repository classes. Still it makes sense to encapsulate them.
I think the way we know DAO's today will change. The idea of having a factory and interface is deprecated for EJB3 + JPA.
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
First of all, DAOs can't be a layer since they have a dependency on business objects. They are an implementation package part of the business layer.
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.
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.
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!
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.
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.
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.
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.
Found an interesting post here about DDD and ORM backed Repositories. And a reaction to that post here.
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!
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.
LOL the joy of copy and paste and of a long day of work!
And not enough coffee? ;-)
I was once a DAO adept. But I've seen many times that it's simple impossible to perform real separation of concerns in practice using DAO.
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.
POJO "business objects" do not belong to either the service or the data acces layer. They form a layer in their own right, and actually a *vertical one* that cuts through the rest application layers.
I searched for a visual representation and this is the closest I could find.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
18 comments
Watch Thread Reply