I've seen a lot of codes use a service-dao pattern , I don't know the origin of this pattern . It force the front layer call service , then delegates some of the service task to dao.
I want to ask :
- Does DAO layer do purely data access related task ? What about things like exception encapsulation?
- Is there any other pattern can be used to replace this or better than this ?
- I think pojo domain models and transaction scripts make even simple problem became complicated , is it possible to completely eliminate dao layer ?
Ideally, your DAO layer 'abstracts away' the access to some data storage system (database, file system, LDAP directory, ...). So in that sense it is used only for data access related tasks. However, you could also have a DAO layer that accesses a web service or some other component external to your application. That's the key point, it provides access to some external component.
The main idea is that there are no implementation details of your DAO layer that escape to higher layers (isolation). A good starting point for thinking about this is: what would I need to do if I plan to replace the component (a database for example) that my DAO layer provides access to? For example, you have some data inside XML files and you plan to migrate the data to a database.
Suppose you have all kinds of XML-related exceptions that escape your DAO layer. Then it becomes quite hard to migrate your XML layer to a database layer. However, if you've encapsulated all implementation details of your DAO layer, this will become a lot easier.
In the end, it's about maintainability of your code. The less dependencies you have on implementation details of a specific layer (services, DAO, ...), the better maintainable your code is.
The main goal of such a layer is to provide abstraction of the persistance back-end. however, most of the times, due to specificities of persistance back-end, total hiding is not possible; A typical example is the query handling. To query a DB using hibernate, you'll write some kind of query code (using HQL, query API, ...) and a totally different paradigm when using JCR, a BigTable, or something else. As a consequence, most of the time, this pattern fails.
Besides there is also the - more annoying - issue of DAO/DTO. You are then pushed forward to write a first class holding your data, then a second copying data from your first one without any added value just for the sake of layer isolation.
There is however some work that has been done in this field. For a micro-framework i've started and implemented for google-app-engine, I've made a little list of so-called dao frameworks easying this rather mundane code.
Notice I plan, in the future, to be able to offer total transparency through gaedo service definition, but it's only a hope ;-) (and is not of immediate interest to you, I guess).
Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation.
Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.
The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.
