3

I'm currently part of a project in which we host a WCF service to be accessed by certain clients. The WCF solution is split up into 4 different C# projects:

Host.csproj
DataContracts.csproj
Infrastructure.csproj
Model.csproj

Upon joining this project, I immediately wondered why there was a separate project for "DataContract" objects and one for "Model" objects. The two projects basically contain duplicates of the same objects. For example, in the DataContract project, there is a Customer object with 4 properties, and the model project also has a Customer object with the same four properties... I noticed that there is A LOT of automapper (mapping) being used in the application code to map datacontact objects to model objects and then re-map model objects back to data-contract objects while flowing through our typical service-repository pattern. The number of mappings necessary to produce results in this service has become extremely annoying.

After asking some teammates about why this route was chosen, I was told that datacontracts should not contain domain logic and that they are strictly objects to be used to send over the wire (and that all domain logic should be done using the model version of the object).

I feel like this approach is a bit unnecessary. Couldn't we just do away with the datacontracts project and use our model objects for both domain logic on the service side and also as datacontracts?

Somebody enlighten me...

user1431072
  • 1,272
  • 2
  • 13
  • 32

1 Answers1

8

Couldn't we just do away with the datacontracts project and use our model objects for both domain logic on the service side and also as datacontracts?

Yes it's physically possible for you to expose your domain objects out of your service, and it might save you a mapping or two.

However let's imagine in the future the domain model changes in response to business needs.

  • The existing consumers are happy with their contracts and don't want to have to change every time you release, so you are limited to a small non-breaking subset of possible changes you can make, or you have to wait until they're ready to release before you can.

  • One day another business consumer comes along who wants to leverage your domain capabilities. But they don't want the same contract as your existing consumers. How can you offer them what they want without breaking your existing consumers?

  • Another development team want to use your domain models in-process so you ship them an assembly, but their deployment server is .net 2.0 so it falls over trying to load System.Runtime.Serialization.dll

More generally, how can you evolve your domain capability when you're hard-wired to your external dependents?

If you think none of these situations apply to you and your service will always and forever be a simple facade on a repository for some ancient and unchanging business function then go for it.

Or,

The mappings you find irritating are there to protect you from inevitable change. As a consumer of a service, being coupled to that service's release schedule is a nightmare, and the same is true both ways. The mappings free you to be able to evolve your domain's business capability as you want to without having to worry about breaking anything. Want to rename a field? Do it. Tired of that massive single class? Refactor it into sub-types. The world is your oyster.

If you're worried about efficiency or performance, an in-process type mapping is several orders of magnitude faster than an out-of-process service call, as to be almost negligible.

So I'm going to have to say the advice your colleagues gave you:

datacontracts should not contain domain logic and that they are strictly objects to be used to send over the wire

sounds pretty smart to me. Lots more here.

If you're finding the mappings tedious, I have used Omu ValueInjector before and it takes alot of the hassle out.

Community
  • 1
  • 1
tom redfern
  • 30,562
  • 14
  • 91
  • 126