10

Typical scenario. We use old-school XML Web Services internally for communicating between a server farm and several distributed and local clients. No third parties involved, only our applications used by ourselves and our customers.

We're currently pondering moving from XML WS to a WCF/object-based model and have been experimenting with various approaches. One of them involves transferring the domain objects/aggregates directly over the wire, possibly invoking DataContract attributes on them.

By using IExtensibleDataObject and a DataContract using the Order property on the DataMembers, we should be able to cope with simple property versioning issues (remember, we control all clients and can easily force-update them).

I keep hearing that we should use dedicated, transfer-only Data Transfer Objects (DTOs) over the wire.

Why? Is there still a reason to do so? We use the same domain model on the server side and client side, of course, prefilling collections, etc. only when deemed right and "necessary." Collection properties utilize the service locator principle and IoC to invoke either an NHibernate-based "service" to fetch data directly (on the server side), and a WCF "service" client on the client side to talk to the WCF server farm.

So - why do we need to use DTOs?

Pradeep
  • 9,667
  • 13
  • 27
  • 34
HenningK
  • 307
  • 3
  • 13

2 Answers2

7

Having worked with both approaches (shared domain objects and DTOs) I'd say the big problem with shared domain objects is when you don't control all clients, but from my past experiences I'd usually use DTOs unless it development speed were of the essence.

If there's any chance that you won't always be in control of the clients then I'd definately recommend DTOs, because as soon as you share your domain objects with someone else's client application you start tying your internals to someone else's dev cycle.

I've also found DTOs useful when working in a versioned service environment, which allowed us to radically change the internals of our app but still accept calls to the old versions of our service interfaces.

Finally, if you have a lot of client applications it might also be beneficial to use DTOs as you're then protected with an easily versionable service.

Ubiguchi
  • 3,066
  • 1
  • 25
  • 24
  • You're right, ofcourse. At some stage we ARE going to involve third parties. But I'm thinking more in the lines of exposing the needed functionality to them as a "superlayer" on top of these WCF services, and only THEN utilising custom DTOs. An Adapter for our WCF service layer, if you like. – HenningK Oct 20 '08 at 21:31
6

In my experience DTOs are most useful for:

  1. Strictly defining what will be sent over the wire and having a type specifically devoted to that definition.
  2. Isolating the rest of your application, client and server, from future changes.
  3. Interoperability with non-.Net systems. DTOs certainly aren't a requirement, but they make it easier to design "safe" types.

In your scenario these design features may not matter that much. I've used WCF with both strict DTOs and shared Domain Objects and in both scenarios it worked great. The only thing I noticed when sending Domain Objects over the wire was that I tended to send more data (and in unexpected ways) then I needed to. This was likely more due to my lack of experience with WCF than anything else; but it's something you should definitely be wary of should you choose to go that route.

akmad
  • 19,343
  • 2
  • 29
  • 25
  • Yep, akmad, these are exactly the kind of thoughts I've been having, too. We're probably going for an approach that kind of mixes this a bit, transferring pure "entities" where appropriate, but doing a more command-based "message" format for purer business-process type calls. – HenningK Oct 20 '08 at 21:30