Domain Objects And Presentation Layer

[ozGuy]

Hi All,

I am about to start a new project and I am undecided on how to link my presentation layer with Domain objects.

Traditionally I have used DTO which means for each Domain Object, there is corresponding DTO. This approach is a overkill and want to see what you guys are doing.

I can think of 3 options and any feedback on this will be much appreciated:

1. Use Domain object directly in the presentation. But this means now the UI can do anything with the domain object such delete, update etc if I am using OpenSessionInView pattern.

2. Use Domain object without OpenSessionInView and any update/loading has to be done within a transaction scope, This means UI can do anything with the Domain object but nothing is made persistent yet until save/update call is made withing a transaction scope. Validation happens before domain object is re-attached/merged with the session.

3. Use ViewObject per page which represents the data needed only to interact with that page. This View Object is similar to DTO except the View Object only contains what it needs to handle the page.

With this 3 options I have confused myself to a level where I can't decide which approach is better.

Any suggestion or pointers would be appreciated.

Thanks in advance.

[SigmundL]

Personally I'm moving towards serving the web client with JSON (AJAX) using DTO's with the desired data.

[F.Degenaar]

Which approach is better depends on the context:
If the application needs to be very scalable, then approach #2 probably works best. No server-side-state is needed as opposed to the other approaches.
If scalability isn't such a concern and your web framework supports it, approach #1 can be implemented very quickly (no DTOs, no reattach).
Approach #3 yields a better separation between web and business layers, which can provide better maintenance in the long run.
When working with Spring MVC I prefer a combination of the three approaches:
Granted, that most operations end up in creating, updating or deleting a domain object, I create command objects, that are composed of the respective domain object as a property and additional properties needed for the use case. That way I have only one object to deal with in the web layer for the whole workflow.
To make the forms small, I use session form objects. This causes some overhead, but statefulness is limited to the web layer and I don't have to put hidden fields into the web forms in order to be able to completely recreate the object from the request.
Instead of a extended persistence context, I manually reattach objects.
Finally, OSIV helps to decouple controllers and views, since the controller can be ignorant about lazy-loading.

HTH