When to use Data Transfer Objects and DataSets

Question

I'm trying to come up with a methodology for when to use Data Transfer Objects and when to use DataTables.

As an example of the problem I'm facing in our system...

We have 6 different business entity assemblies representing the same things but with different properties. They have been created by several developers concerned with different problems over a period of several years.

For example different applications using the "Bicycle" class over the years were concerned with different properties of the bicycle. So they called different data methods that only retrieved and populated the properties they were concerned with.

Data Service 1 Populates

• Brand
• Color

Data Service 2 Populates

• # Gears
• Tire Size

and each uses a different business entity. Clearly this is ridiculous, you can't be creating a new class for every possible combination of properties.

My gut feeling tells me that if this is a problem then we should probably be using an ORM.

But for the time being I want to say.

• If you are populating or returning an entire row from a table then use the DTO / Business Entity that matches the database.

• If you are returning a random set of properties then use a datatable.

Could anybody offer some guidance?

Thanks

Answer 1

I would keep it simple and always return a DataSet -- in short, use DataSet as a generic DTO. It's flexible, it's type-safe, it's available. Unless you get into some very hairy nested object models, DTO's won't buy you anything for the effort.

Answer 2

This will vary based on the size of the system we are talking about. If these are really separate systems, then it stands to reason they work with different ways of viewing the same concept. This is called bounded context: http://domaindrivendesign.org/discussion/messageboardarchive/BoundedContext.html

If that were the case, the probably problem you would have is that you are communicating between different bounded contexts through the database, instead of explicit boundaries, usually at the API level.

Also note that managing or returning a subset of information, doesn't necessarily means using a separate class. You could have a shared class implement different interfaces, so the calling code is able to deal with a subset of the information.

Answer 3

There's nothing wrong with separating entities from the database. You can do this easily with Entity Framework. You can have multiple entities mapping to the same table or set of tables, each with different sets of properties.

Now, on the other hand, there's also no reason not to standardize on a common "Bicycle" definition. If data service 1 wants to update just the brand and color, it can have an UpdateBrandAndColor operation. It doesn't need to pass the entire entity, just its id, brand and color. Same with #gears and tire size.

But there should only be a single Bicycle entity type returned from the GetBicycle operation.