Geek Answers Handbook

When to Use Data Transfer Objects and DataSets

I am trying to develop a methodology for using data transfer objects and when to use DataTables.

As an example of the problem that I encountered in our system ...

We have 6 different assemblies of business objects representing the same things, but with different properties. They were created by several developers who have been dealing with various problems for several years.

For example, various applications that use the Bicycle class over the years have dealt with various properties of a bicycle. Therefore, they called different data methods that only retrieved and populated the properties with which they were associated.

Data Service 1 Configures

  • Mark
  • Color

Data Service 2 Configures

  • Gears

  • Tire size

and each uses a different business object. Clearly, this is ridiculous; you cannot create a new class for every possible combination of properties.

The feeling of my feeling tells me that if this is a problem, we should probably use ORM.

But for now I want to say.

  • If you are populating or returning a whole row from a table, use the DTO / Business Entity, which corresponds to the database.

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

Can anyone suggest some kind of guidance?

thanks

+4
source share
3 answers

This will depend on the size of the system we are talking about. If these are truly separate systems, then it is reasonable that they work with different ways of viewing the same concept. This is called a restricted context: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html

If that were the case, you probably would have a problem with you linking between different restricted contexts through a database instead of explicit boundaries, usually at the API level.

Also note that managing or returning a subset of information does not necessarily mean using a separate class. You may have a general class that implements different interfaces, so the calling code is able to process a subset of the information.

+5
source

I would leave it simple and always return a DataSet - in short, use a DataSet as a generic DTO. It is flexible, it is type safe, it is affordable. If you don't fall into some very hairy nested object models, DTO won't buy you anything for that.

+5
source

There is nothing wrong with separating objects from the database. You can do this easily with the Entity Framework. You can map multiple objects to the same table or set of tables, each with different sets of properties.

Now, on the other hand, there is no reason not to standardize the general definition of “bicycle”. If Data Service 1 wants to update only the brand and color, it may have an UpdateBrandAndColor operation. He does not need to convey the whole entity, its identifier, brand and color. Same thing with C # gears and tire size.

But there must be only one type of Bicycle object returned from the GetBicycle operation.

+2
source

More articles:


All Articles