Multiple data access objects?

I'm introducing Spring gently into an existing webapp, and am trying to get my head around certain aspects of it. I've read tutorials showing the creation and use of a data access object (interface and implementations thereof). But what is not clear to me is whether one such DAO is required/desirable for each type of data I might be wanting to persist. For example, the tutorials show a DAO with methods like getProductList and a private inner ProductMappingQuery class. So, would I use that same DAO class for customer and order queries, for example? Or should I have a ProductDAO, a CustomerDAO, an OrderDAO and so on? That is, a matching DAO for each type of object I want to persist (or looked at alternatively, for each table in the DB)? This latter seems the obvious thing, but the tutorials don't go that far.

You didn't specify what data access mechanism you were using, but I'm going to assume that you are using JDBC. Multiple DAO's vs Single service classes are really a matter of preference. It is possible to use a single class as your DAO (see the org.springframework.samples.petclinic.hibernate.Hi bernateClinic class in petclinic sample app), but it is just fine to use a DAO class per persitant object (IE PetDAO, OwnerDAO, etc).

A lot of times you'll see a single service class that will use multiple dao's to enclose an operation spanning multiple persistant classes into a single transaction, or for ease of access. The private inner class is just to represent a query, so in the case of a JDBC DAO per persistant object, you will have numerous inner query classes per DAO.

This is one place where software becomes bit of a craft/art, but yes, in general, you'll see it's good practice to have access to a particular entity (for example via relavent CRUD methods) behind a single DAO interface, with one or more implementations for the various data access strategies you wish to support.

But there's nothing wrong with getting creative; for example, possibly defining a DAO interface for each entity, but having a more coarse-grained implementations that performs data access for a set of related entities. Or for a small app, a single DAO interface might be plenty, see the Petclinic sample for this. I know sometimes I don't want to create a ton of fine grained DAO implementations, each one mapping to a specific table.

The important thing to remember is a DAO method generally executes a single operation against a DB; typically a higher-level service object is responsible for wielding those low-level DAO calls as part of a system transaction (e.g accross multiple DAO operations.) While it is feasible to combine the DAO/service responsiblities into one object for a small app without a lot of business logic, it's generally not recommended as you tie your business logic to your data access strategy.

Quote:

---

Originally Posted by ryan.tyer

You didn't specify what data access mechanism you were using, but I'm going to assume that you are using JDBC. .

---

Yes, that's right. Thanks for the guidance.

Quote:

---

Originally Posted by kdonald

This is one place where software becomes bit of a craft/art, but yes, in general, you'll see it's good practice to have access to a particular entity (for example via relavent CRUD methods) behind a single DAO interface, with one or more implementations for the various data access strategies you wish to support.

---

The mists are beginning to clear...

Quote:

---

The important thing to remember is a DAO method generally executes a single operation against a DB; typically a higher-level service object is responsible for wielding those low-level DAO calls as part of a system transaction (e.g accross multiple DAO operations.) While it is feasible to combine the DAO/service responsiblities into one object for a small app without a lot of business logic, it's generally not recommended as you tie your business logic to your data access strategy.

---

Yes, I've been reading an article by Mark Eagle on using Struts, Spring and Hibernate, and he uses as his example an IOrderService interface which belongs to the business layer, containing a setter method for an OrderDAO object (once again using an interface), which belongs to the data persistence layer. The controller talks to the business service without having to know anything about the data access objects.

It all makes eminent sense to me, it's just a case of learning to incorporate it all into my way of design.