This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

business layer vs dao layer

Nov 16th, 2004, 01:31 PM

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?

Comment

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.

Comment

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.

Comment

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.

public interface Dao &#123;
public long create&#40;PersistableEntity object&#41;;
&#125;
public interface BillingManager &#123;
public long create&#40;Bill bill&#41;;
&#125;

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.