business layer vs dao layer

[dougp]

from what i've seen, the business layer methods delegate to dao methods with the same signature. where is the value doing that? Can you give me some examples, maybe using jpetstore or petclinic, that would have a business layer that did something other than delegate to a dao?

would an example be discounting prices by 10% if it is Tuesday? Inside the business method, you'd retrieve the products and then decrease the price before returning them back to the controller?

[katentim]

DAOs usually implement a single re-usable operation that usually has no business knowledge.

The business layer is actually implementing business logic using those DAOs - your example is a good one. It is also often convenient to just define your transactions at the business layer level.

[gweatherall]

We have just started using Spring, and we had similar thoughts to your original post. We found that over time our business layer contained a mixture of calls that just passed thru to the DAO layer, and some calls that added business logic. Our business layer became a kind of facade, hiding the DAO layer.

[rhasselbaum]

We expose both Business Service Objects and a few DAOs to the client layer. This has worked out very well, as there are times when the UI just needs to fetch some objects for display and other times when it needs a service for some business task. The right tool for the right job.

[arikkfir]

I think there should always be a facade (usually thin) layer between the UI and the DAOs. That's because requirements shift and change constantly, and what appears as a simple request for some objects layer becomes a complex request which needs more DAOs and such. Changing the DAO to call other DAOs is possible, but what if other facades/UIs depend on that DAO method to return the old values?

I believe there should be a facade for each form, which calls DAOs or other facades. If several forms have similar requirements, then their respective facades should call a common facade which calls the DAO, but this is optional.

But he one rule we always mandate is that DAOs are never exposed to the client.

Just my 2cents, cheers ;-)

[Ben Alex]

Good points are made above. The services layer is also the place to put your transaction and security interceptors, not against the DAO.

Also, in our applications our DAO hierarchy extends from a base which provides CRUD operations for a generic PersistableEntity, whilst our services layer works with specific domain objects:

public interface Dao {
  public long create(PersistableEntity object);
}

public interface BillingManager {
  public long create(Bill bill);
}

Thus a services layer also handles casting to/from the generic DAO as well. I find it surprising how often people write a fresh DAO for everything, when using a generic base like this will save them a lot of duplication.

[arikkfir]

I agree - JDK1.5 Generics even make this more beaufiful:

public interface BaseDao<T> &#123;
        T findByPrimaryKey&#40;Key<T> pKey&#41;;
        List<T> findAll&#40;&#41;;
        ...
&#125;