To DTO or not to DTO???

[garpinc2]

I have read many articles on this topic and in the end all I have ended up being is confused.

Some articles say to use Hibernate Business Objects instead. The problem I see here is that you have to assemble the Business objects and this can involve business logic (conditions as to what data needs to go where, when, selects from the db, validation etc). So the Action class doesn't appear to be the place for this. Refactoring all this logic out into the service layer leave you with one of 2 solutions. a) Method signatures of the service methods either have all the parameters necessary to fulfil the requests or b) Method signatures accept DTOs which encapsulate all the parameters necessary to fulfil the requests. So this is contradictory to the "use Hibernate Business Objects instead". For responses which return Hibernate Business Objects I don't see any issues but for requests are DTOs not generally necessary.

[Rod Johnson]

I have to admit that I don't fully understand your question. However, I strongly recommend the Persistence chapter of J2EE without EJB, in which Juergen thoroughly discusses DAO design, including in combination with Hibernate.

We normally recommend using persistence framework-agnostic DAOs with Spring, so they shouldn't be "Hibernate" DAOs and you shouldn't use Hibernate in your service objects.

[garpinc2]

I am using all the techniques from the book wiring up my application similar to article http://www.onjava.com/pub/a/onjava/2...ngwebapps.html.

What I found was:
The more I tried to avoid the use of a DTO for saving screen data the more of my code got in the controller layer instead of the service layer. In fact my service layer became almost a mirror of my dao interface ( yes I am using persistence framework-agnostic DAOs ).

The reason for this is that then the bulk of my code in the controller layer was the manipulation of screen objects to transform them into an object graph. Finally when the object graph was populated all that was necessary was then to persist it with simple saves.

So with all this code in controller layer and hardly any code in service layer I got to thinking that this can't be right. Enter the DAO which I was trying to avoid (as advised) . The only way to move the logic to the service layer was to pass the data as raw as possible and then do the assembly in the service layer.

So that's why I am confused. What is the best practice here "to DAO or not?" and if so why.

[garpinc2]

Never got an answer on this... If anyone has any ideas please respond.

[gmatthews]

For my 2c, It's a bit of a gray area but I think the goal for bulding a business logic layer is simply to have a highly intention revealing -- since this is the high value area, and most of the rest of the app is relatively throwaway compared to this.


We tend to lean towards using Hibernate objects as parameters to business methods where you're building an edit page or something where the business method is interested in most of the fields within the Hibernate objects, and the business object will mostly just delegate to the persistence layer.

Upside:
- can use Hibernate directly for persistence, get consistency of field names/data types used to represent data.
- if you change your db and then regen Hibernate, the compiler will beep at any dependent code that needs changing.


We tend to lean towards passing individual parameter fields or made up parameter holder classes for wizards or other pages where you may not be interested in all of the fields of the Hibernate object(s), or where you may be passing a number of directive type parameters/flags.

Upside: business method doesn't receive a whole bunch of stuff it doesn't need

Downside:
- got to manually move data into Hibernate objects if you want to do Hibernate stuff.
- might end up with different names through the app for field names at various app layers

[garpinc2]

With the first option as I discussed then
1) the business logic to decide how to populate the hibernate object depending on the screen interaction is in the action class. i.e remove or add an entry from of collection.
2) Success notifications based on successful occurences of the intermediate steps are captured in you action classes

Is this your general practice?

If so then on a save what do you actually do in the business layer besides just save, update and delete. What business logic to you keep in the service layer.

[gmatthews]

Yes -- business logic layer doesn't know about any layers above it.

Some success/progress notifications would be generated out of the business logic layer while others would be generated out of the service layer. Business layer doesn't know about http requests so passes messages, etc, back as return values or by reference.

The service layer should ideally be kept fairly devoid of business logic. Every couple of code reviews, I push bits and pieces that have accumulated in the service layer (and starting to look like business logic) down into the business logic layer.

Having read Martin Fowler's "Refactoring:Improving the Design of Existing Code" book is also useful as part of the constant refactoring exercise to keep the various application layers in good shape.

[garpinc2]

Aren't you confusing business layer and DAO layer? The service layer is where business logic should be shouldn't it and the DAO layer should be devoid of business logic. Isn't that what you mean't to say?

ie: Action -> Service Layer -> DAO layer

[gmatthews]

Hi,

Yes, agree, but we're using different terminology.

By service layer, I meant the layer that talks to your high-value business logic layer. The service layer might be an upper layer of a web app or MDB or rich client, etc. or any layer that handles the conversation with the client/end-user.

The advice I follow is, as the first priority, to create a highly descriptive business logic layer (service layer?) API and sort of let the whole DTO/DAO argument come second place. A close second place, but second place nonetheless.

Your gut instinct seems to be telling you this also ... "So the Action class doesn't appear to be the place for this"

Hope this helps,

Regards,
Greg.

[garpinc2]

Thanks for your opinion:

Please others provide comment on this important topic!! Rod Johnson and company especially.