DTOs and interfaces

Question

I recently ran across this pattern(?) in our code and wondering how it is useful, if at all. We have a Spring app and a Flex front-end using BlazeDS. It was decided that we use interfaces on our DTOs, like so:

Java

public interface ISomeDTO {
       Integer setId();
       void getId(Integer i);
}

public class SomeDTO implements ISomeDTO
{
..
}

Actionscript

public interface ISomeDTO {
       var id:Integer;
}

public class SomeDTO implements ISomeDTO
{
..
}

What does an interface on a DTO gain you? These are lightweight objects with absolutely zero logic. DTOs make sense, interfaces make sense, but not together.

Answer 1

In a transaction based environment DTOs are used to split your database entities from the underlying db session.

These sessions are normally unavailable and most entities are made up of proxies which lazily load member collections. So if you were to access a collection property on a proxied entity the proxy loads the collection at this point in time, wether there exists a database transaction or not. So an access of an entity member could spawn a fault when there is no active transaction.

Exactly this happens when you forward your entities to the view, which tries to access a member. Since transaction handling is normally defined in the service layer, there is no active transaction in the view/controller.

To circumnavigate this problem there are different approaches:

• Keep the Session open through e.g. a Filter mechanism (Spring's OpenSessionInViewFilter), though strictly speaking this is an anti-pattern
• let your DAOs return a Data Transfer Objects filled with the needed members already initialized

hope this helped.

Answer 2

I don't see why interfaces and DTO's would not work together.

Consider a factory/assembler that creates domain objects from DTO's. You could configure the factory with strategies so that it is able to create specific implementations of a domain object based on the type of DTO it is given. The DTO would ideally be typed to an interface here. (This works in the opposite direction as well).

I'm not saying that you should put every DTO behind an interface, but just as with domain objects, there will certainly be cases where it is beneficial to do so.