Data Transfer Objects
Microsoft Dot Net uses Data Transfer Objects as a technique for packaging and serializing data to and from their web server systems. Some applications may even use DataSets as a Data Transfer Object http://msdn.microsoft.com/en-us/library/ff649325.aspx. Other implementations may use a class, multiple or complex classes with collections. I have seen WCF tend to lean towards Class based DTOs because of the strong typing of the objects.
This implementation of DTOs results in the ability to have strongly typed client and server sharing native POCO (Plain Old CLR Objects) objects, by sharing a common interface on the client consumer and the web service. I find this makes programming a little bit easier to understand and quicker to code in Microsoft technologies, allowing Visual Studio intellisense to work regardless of client or server code.
Data Transfer Objects come with a cost. The contracts in this case are Dot Net specific. If your web service supports other clients using standard generic SOAP communication techniques, DTOs and POCOs will not work. You have to write the code twice using standard SOAP definitions, or not use DTOs at all.
Secondly, your Data Transfer Objects do not support methods. They only support properties. Adding a ToString() method to your DTO Class will compile, but a call to ToString() on a DTO results in nothing. This means you can’t use classes from your business layer as data transfer objects with their full functionality.
Finally, you must decorate your DTOs in order for WCF to implement them correctly, and expose the internal details of your DTO to the Web Service consumer. This is once again a Microsoft supported only technique. As a result, most of the examples I have seen maintain two sets of objects…Data Transfer Objects and Business Objects. They may be identical in most ways, or radically different. How they are defined depends on the usage required.
One big advantage of DTOs when working with them in the Microsoft stack is that it takes the burden off of serialization. Dictionaries and other collection objects serialize easily compared to the same using XML or JSON. And, as I have alluded to above, having DTOs in your code enables intellisense when using these objects in Visual Studio, making it easier to code.
If you’re interested in more information about Data Transfer Objects, check out this site …http://msdn.microsoft.com/en-us/library/ff649585.aspx.
So, there is a quick trip down the DTO trail. Hope it is entertaining. If you have tips about how DTOs may be used more effectively, drop us a note by writing in to btaylor@sswug.org. Why not share how the use of DTOs changed you?
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Troubleshooting problems with SQL Server 2008 R2 Query Notifications
In this article, Alexander Chigrik explains some problems that you can have when you use SQL Server 2008 R2 query notifications.
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)