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

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://dddcommunity.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.