What about versioning?

Nov 12, 2009 at 8:17 AM
Edited Nov 12, 2009 at 8:18 AM

Hi Julius,

I've read your article in july's dot.net magazin (Gemany) and was curious about this DataTransferObjectManager. I had the same idea, but I've dropped it, let me explain why.

We were following the P&P Web Service Software Factory and created a WCF solution with a repository access layer, a business layer (domain + logic) and the service layer which consists of four libraries: data contracts, service contracts, fault contracts and the service implementation. First I spent considerable amount of time to write the mappers between data contracts and business entites. Second I spent another considerable amount of time to write interactive code snippets for visual studio to reduce the amount of time to do the mapping. However I thought that this is so stupid, that we should think about doing this by a smart mapper class. But there was one problem: The basic idea that was important for us was the ability to support different versions of the service facade with the same business logic in the back. Having two different versions of contratcs where properties have been changed or renamed will break this idea. And the encapsulation of your business domain is also non existent, if you map it 1 by 1 by default.

So my opinion is that this is a smart and nice idea, but in practice, it violates the encapsulation theory behind data transfer objects and makes versioning of service APIs impossible.