10

Why should I use DTOs/Domain objects when I can just put all business classes in a class library, use them in the business logic, then also pass those same business objects on to boundary classes?

UPDATE: All are great points, thanks for the help. A follow up question:

Where do you typically place these DTOs? Alongside the Domain objects i.e. in the same namespace?

namespace MedSched.Medical { public class MedicalGroup { //... } public class MedicalGroupDTO { //... } }
Improve this question

4 Answers 4

Reset to default
10
  • The DTO's provide an abstraction layer for your domain model. You can therefore change the model and not break the contract you have for your service clients. This is akin to a common practice in database design where views and procedures become the abstraction layer for the underlying data model.
  • Serialization - you may over expose data and send bloated messages over the wire. This may be mitigated by using serialization attributes, but you may still have extra information.
  • Implicit vs. Explicit Contracts - by exposing domain objects you leave it up to the client to interpret their usage since they do not have the full model at their disposal. You will often make updates to domain objects implicitly based on the presence or removal of associations, or blindly accept all changes. DTOs explicitly express the usage of the service and the desired operation.
  • Disconnected Scenarios - having explicit messages or DTOs would make it easier for you to implement messaging and messaging patterns such as Message Broker, etc.
  • DDD - pure DDD demands that domain objects are externally immutable, and therefore you must offload this to another object, typically a DTO.
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

5

I can think of 2 basic scenarios for using DTOs:

  • You're creating your business object from data that's incomplete and will fail validation. For example, you're parsing a CSV file or an Excel file from where your business object is created. If you use data directly from these objects to create your business object, it is quite possible to fail several validation rules within the object, because data from such files are prone to errors. They also tend to have a different structure that you have in your final business object: having a placeholder for that incomplete data will be useful.

  • You're transporting your business object through a medium that is bandwidth intensive. If you are using a web service, you will need to use DTOs to simplify your object before transport; otherwise the CLR will have a hard time trying to serialize all your data.

Improve this answer

Comments

4

DTOs are Data Transfer Objects, with Transfer being the key word. They are great when you want to pass your objects across the wire and potentially communicate with a different language because they are "light weight" (ie no business logic.)

If your application isn't web service based, DTOs aren't really going to buy you anything.

So deciding to use or not use DTOs should be based on the architecture of your application.

Improve this answer

2 Comments

Makes sense - yes, the particular app in question is a highly-distributed app. Thanks for the input.
Distributed in what sense? If you are using a remoting like technology, you can usually still serialize your Domain Objects and pass them across boundaries without any issues. Once you start getting into different platforms, DTOs usually make things easier.
1

There are times when the data you want to pass around doesn't map exactly to the structure the business objects, in which case you use DTOs.

Ex: when you want to pass a subset of the data or a projection.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.