Menu
We are using Dtos in our WCF service interface, but have started to come across issues when the Business Object that the Dto represents implements more than a single interface and we want to return the Dtos in those different contexts and to also be able to treat the Dtos polymorphically on the client.
For example lets say we have an interface for an IBusinessObject with several properties containing details of the relationships of the object, attributes of the object etc etc. I have several implementations of this one being a LinearBusinessObject which implement IBusinessObject and ILinear. There are other implementations of ILinear which are not also business objects, just simple linear things.
Our service has a method to get a business object. This returns a base Dto class (BusinessObjectDto) which declares the common parts of a IBusinessObject (relationships attributes etc) and the LinearBusinessObjectDto which extends BusinessObjectDto and adds the extra information about the linear side of things. This is fine and enables the client to treat the returned BusinessObjects with some degree of polymorphism.
We also want a method which gets a Linear thing. This returns a base class LinearDto which contains the common linear details. The simple linear object implementation extend LinearDto and all is good. But now I have a problem, as I can't have my LinearBusinessObjectDtoextend from both LinearDto and and BusinessObjectDto as only single inheritance is supported, and I can't use interfaces as WCF doesn't know what types to then put in the service contract definitions in the WDSL.
So I've started having 2 dtos for my LinearBusinessObject, one which derives from BusinessObjectDto (LinearBusinessObjectAsBusinessObjectDto) and one which derives from LinearDto (LinearBusinessObjectAsLinearDto) and then converting each one based on the interface I'm interested in.
This seems like its going to result in many extra Dto classes (of which I already have many) and so I'm wondering if there is a better solution than this? Or is this just something we have to live with?
230
DTOs may inherit properties from multiple interfaces and using interfaces may reduce casting data between components and modules, especially in the boundaries of a single solution. Also, rules are often applied on interfaces, so DTOs should use them.
Your class can implement more than one interface, so the implements keyword is followed by a comma-separated list of the interfaces implemented by the class. By convention, the implements clause follows the extends clause, if there is one.
A data transfer object (DTO) is an object that carries data between processes. You can use this technique to facilitate communication between two systems (like an API and your server) without potentially exposing sensitive information. DTOs are commonsense solutions for people with programming backgrounds.
DTO stands for Data Transfer Object. This is a pattern, widely used in the backend, in which you decouple types used for data transfer from the actual data model. In our example, the changes in the API will be reflected in the UserDTO type.
A wise man once told me that Object Orientation is the enemy of services.
It seems to me that this is a general OO/SOA problem rather than a specific WCF problem: the old advice of "Favor Composition over Inheritance" comes to mind. When it comes to services especially, Polymorphic designs should not be what you are after in your DTO layer. You should avoid using DTO's that use inheritance or Interfaces (and interfaces are not even possible unless you are serializing/deserialising dynamically...you can't generate concrete proxies using SVCUtil as the concrete types are not known at generation time, but from my memory this is possible when using ChannelFactories in your .NET client...I can't remember the details though).
In general when you create DTO/DataContracts only define members/properties in them that are concrete. Your DTO model should be designed to be flat and cross platform, not Object Orientated.
166
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
