Where to put business logic with DAO pattern

[sniederb]

Hi

I'm familiar with the DAO pattern and can read everywhere that it enables to separate data access from business logic. I'm now designing an application with some heavy business logic and encouter the following dilemma:

Given an OrderDataTransferObject (OrderDto) and a OrderWithBusinessLogic (OrderLogic), how do I link these two? I'd actually like OrderLogic to extend OrderDto, as this will automatically give getter / setter methods for all relevant attributes, of which I can override those which trigger some business logic.

Using hibernate however, my DAO implementation will deliver a OrderDto, not an OrderLogic. I find some patterns where OrderLogic contains an OrderDto as delegate, but I find this solution inferior, as adding a new DB field will require changing both OrderDto and OrderLogic.

What is the "Spring-way" to do this?

Thanks
Simon

[cepage]

The purpose of using a DTO is to have a class that is decoupled from your domain class, because the domain class can not be effectively reused in certain layers of the architecture.

When you establish an inheritance relationship, you are really at cross-purposes with the whole decoupling goal.

Yes, by decoupling the DTO from the domain object, you will have some getters and setters that are repeated between the classes, and that is not entirely optimal.

But I think it's less messy than the situation you will encounter as your application evolves, when your DTO ends up needing to implement formatting, display, or serialization methods that don't belong in the domain object.

[sniederb]

Hi corby

thanks a lot for your reply. I was under the impression that I had obviously not entirely understood the pattern, exactly because of repeating all those getter/setters. You reply tells me that we're on the right track.

Thanks
Simon

[jmikres]

Another suggestion would be to implement the use of Hibernate - thus being able to use your domain classes within a persistence layer. I would really rather not build a DAO persistence layer from scratch since Hibernate is so good. We've built a lightweight persistence layer following the TableDataGateway pattern from P of EAA based on Hibernate. THis layer is responsible for performing the hibernate type of work for us i.e. saveOrUpdate(), update(), etc. type of invocations on the domain classes themselves. When doing queries with hql - you can retrieve collections of the actual business objects - or do scalar queries in which case you get Object[] of data back that must be mapped to your domain classes. Remember to put your business behavior where it belongs - in your domain model. Don't get trapped in the Anemic domain model anti-pattern . Good luck.