How to model and handle presentation DTO's to abstract from complicated domain model?

Asked 2010-04-11T20:36:04.753

Hi I am developing an application that needs to work with a complex domain model using Hibernate. This application uses Spring MVC and using the domain objects in the presentation layer is very messy so I think I should use DTO's that go to and from my service layer so that these match what I need in my views. Now lets assume I have a CarLease entity whose properties are not simple java primitives but it's composed with other entities like Make, Model, etc

    public class CarLease {
        private Make make;
        Private Model model;
        .
        .
        .
    }

most properties are in this fashion and they are selectable using drop down selects on the jsp view, each will post back an ID to the controller.

Now considering some standard use cases: create, edit, display

How would you go about modeling the presentation DTO's to be used as form backing objects and communication between presentation and service layers??

Would you create a different DTO for each case (create, edit, display), would you make DTO's for the complex attributes? if so where would you translate the ID to entity?

how and where would you handle validation, DTO/Domain assembly, what would you return from service layer methods? (create, edit, get)

As you can see, I now I will benefit by separating my view from the domain objects (very complex with lots of stuff I don't need.) but I am having a hard time finding any real world examples and best practices for this. I need some architecture guidance from top to bottom, please keep in mind I will use Spring MVC in case that may leverage on your anwser.

thanks in advance.

Edit Report

2 Answers

For what it's worth (I'm developing in C# .net - but the principles should hopefully still be helpful to you) I've defined a bunch of types (DTO's) which I use to exchange data between the business and data tiers; and I have more than one type per domain object / entity. These are defined as simple classes.

Each of these is built with a specific task in mind, for example:

I have a light-weight type designed to populate list views (lots of "rows" but not many "columns"). I also have a corresponding collection type that holds any number of these.
I have a "big" get copy which usually has all the properties of the entity in question - but for only one instance of it. I may have more than one of these depending on the size and complexity of the entity vs the cases of use; and also depending on whether you want to return all the data associated with an instance of the entity straight away, or lazy-load some on later requests.
I also usually have separate "save" (new) and "update" types for the entity.

Each type is designed to hold only the information relevant for a given task. For example the "big" will return the date last modified, but I don't expect that in my save and update types because I populate those in the data access layer.

Also, for my app, these types exist in a common assembly - so they can be re-used between any tier, not just between the business and data tiers.

Architectural Fit

There's nothing particular special about this approach, it has it's own pros and cons; exactly what those are and how they affect you will depend on a lot of things - I guess your mileage will vary - but it's certainly served me well for a number of years now.

People often make a fuss over "separation of concerns" - and that's a really wise move; this relates to DTO's in that they are exchanged between layers (and services, components, etc) so there can always some amb

answered 2010-04-11T21:56:49.830

The idea that the service layer should return DTO's instead of EJB objects is mostly a pre EJB3/JPA era idea. During CRUD you really gain a lot from working with the model objects (a.k.a. entities) directly.

You can however benefit from using DTO's when used for performance optimizations, for example when model objects are too bulky or when you gain from using some smart joins for aggregating model data.

So unless you are engineering under SOA, I would not recommend working with DTO’s for CRUD operations.

answered 2010-04-11T22:20:09.697

How to model and handle presentation DTO's to abstract from complicated domain model?

2 Answers

Your Answer