Iterfaces inplace of DTO

[zooxmusic]

Hi all,
I think I know the better answer but I just wanted some input. I only pass DTO's over the wire. (In the body of a Message object)

I at the very least have 2 implementations of my objects. A DTO implementation and a DomainObject implementation.

interface IMyObject

MyObjectDTO implements IMyObject
and
MyObjectDomainObject implements IMyObject

I have been sending the interface over the wire and then packaging the interfaces and the DTO's to be distributable in a common lib but I am now thinking I should just pass an AbstractDTO back and forth.

For one my MessageBody has to take an Object and I would rather it be a little more strongly typed. (ie. AbstractDTO)

Anyone have any thoughts/patterns/experience?

Brian

Spend like you don't need the money,
love like you've never been hurt and dance like nobody's watching!

 

[zooxmusic]

You know what. I am going to use a web services and stop trying to re-invent the wheel.

Brian


Spend like you don't need the money,
love like you've never been hurt and dance like nobody's watching!

 

[chiph]

Actually, I was thinking of replying that it looks like you're trying too hard.

Make the DTOs responsible for serializing themselves and you eliminate about half your work. You'd just need one interface then that each DTO would implement for serialization/deserialization. Instead of one for each type of DTO.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[grooke]

I think that for small projects, Chip H is correct; certainly prgamatic. However, I am worried by the concepts you seem to present. Maybe I have the wrong end of the stick, but your question does not make sense to me.

DTOs are not Domain Objects and vice versa. They each may have different data and certainly different functionality. I think you have confused the two concepts.

A domain object hold all the information about a set of objects of type x. It may be a sub-class of an abstract class X and it may include a number of objects of type y. It has structure.

A Data Transfer object holds the data appropriate to the transfer; perhaps all the data required to display a screen. This may include a few, but not necessarily all field from X and x. It may also include just one of the y objects, but again not necessarily all the fields. It may also have attached the 'signature' of the person displaying the screen, which is not included in the domain objects x or y.

Because their data is different, then their methods will also be different, although there may be a few that are similar, such as a subset of the access methods (getter and setters).

Now if the interface 'IMyObject' just covers some of the methods that are common, then what you say could be correct. But in general, this is not true.

Given that you do have a special case, then a generic DTO does make sense to me. But I would firstly re-inspect the nature of the problem you seem to be facing before going into more complex discussions.

If I have missed the point, then please explain why, because I'm in marginal territory, knowledgewise.

Gil

 

[zooxmusic]

Thanks grooke,
I did kind of think that was the case but wasn't really sure.

Brian


Spend like you don't need the money,
love like you've never been hurt and dance like nobody's watching!

 

[dragonwell]

Hey Brian,

Could you look at thread796-1127762 ? I think I am running into the same issue as you. I am leaning toward some kind of DTO, but don't want to have to deploy it...

Thanks!

 

[BobRodes]

If you're going to use an interface to expose data transfer functionality, the point behind it is to standardize the way that implementers of the interface provide data. They can get the data any way they want, but any consumer can call the methods provided by the data provider and get the data.

A good example of this is an OLE DB data provider. The ADO Conection has a Connectionstring property of type String which is parsed by the provider when the Connection object's Open method is invoked. This does not vary. However, the way in which the provider exposes a connection is up to the provider. Similarly, the ADO Recordset's Open method will use whatever connection is specified in the passed connection object. Of course, the Recordset can also use a string and no Connection object; this is an example of overloading. It is required that any entity wishing to create a data provider implement both versions of the Open method in some way, even if it be throwing an exception.

Now, in your example, if I understand your MessageBody correctly, that's the consumer. It would like to access data transfer in a consistent way. Any data providers that you have would implement the interface that any consumers would use. In this way, the consumer doesn't have to care what the provider needs to do to provide the data, and can just write to the interface.

HTH

Bob