1

I have a large collection of domain models in a core library which also contains methods for getting various sets of models. Multiple WCF service projects reference this library and publish the sets e.g.

GetProducts(int categoryId)

My initial approach was to decorate the domain models with DataContract and DataMember attributes and return them from the WCF service methods. However I see the flaw in that approach as now some services want different model properties serialised to others.

I think I have 2 choices:

  1. In each WCF project create DTO classes with necessary properties and attributes for that project and return these from the service methods. Construct the DTOs from the domain models. This looks like the "right" approach but extremely time consuming to set up and maintain as domain models expand.

  2. Write my own xml serialiser that dynamically chooses which properties of the domain models to serialise at runtime, depending on the project. I have no idea if this is even possible!

(I also considered the "trick" of setting the properties I didn't want serialising to their default value then changing them back after serialisation but its too fiddly and smells bad)

Is there any other approach or is there a way to reduce the manual work involved in #1?

Laurence
  • 980
  • 12
  • 31

2 Answers2

1

Approach #1 in the right one. Design the DTOs so that they meet the requirements of the client and make sure it works fine with WCF.

The mapping from domain objects to DTOs is something that can be greatly simplified by using an object to object mapper. AutoMapper is a common choice in .NET projects. It is flexible and has good performance.

theDmi
  • 17,546
  • 6
  • 71
  • 138
  • Thanks thats just what I need to make the job easier. Checking out Emit Mapper as it seems to have mich better performance than Auto Mapper. – Laurence Jan 09 '16 at 17:48
  • @Laurence AutoMapper has good performance if you use it correctly. Emit Mapper is not supported, the newest NuGet package is from 2011. I don't recommend using it anymore. – theDmi Jan 11 '16 at 08:38
  • Good point. As I get more deeply into choosing a mapper, there are many considerations to think about! Found a good overview of choices here: http://featuretests.apphb.com/ObjectMappers.html – Laurence Jan 11 '16 at 11:14
0

There is a 2b variant. If you mark the objects with [DataContract] and properties with [DataMember] attributes only those will be serialized.

i've used this approach with some success. The question really becomes are it always the same properties that you want to serialize. For example if you have access to the address object and then everything in the address class is publicly visible this is viable. Even if you keep internally a set of geo coordinates for some distance algorithm that you don't expose.

However if some people do, and some people don't have access to a customer's full creditcard number then this approach will be a problem if you try to serialize the customer. (access to a customer's address can still be separately determined if address is a separate object).

Maybe not the best example from a ddd perspective since address probally wouldn't be an entity but i hope you understand my considerations

Batavia
  • 2,497
  • 14
  • 16
  • The question was how to serialise different properties for different clients, not how to serialise in general. – Laurence Jan 09 '16 at 17:51
  • so if they always expose the same properties for the same objects then this approach still would be viable. you could even make your own version of datacontract/datamember that got serialized for a specific serializer but i wouldn't say that is a feasable approach if the number of variations increase – Batavia Jan 10 '16 at 19:13