Friday, 6 September 2013

Are there issues with reusing common code in WCF service versioning implementations?

Are there issues with reusing common code in WCF service versioning
implementations?

I have to modify a WCF service contract with some breaking changes so I'm
trying to implement service versioning for the new contract.
The examples I've seen for doing this seem to always involve creating a
completely new implementation and interface contract in a new namespace.
The problem I have with this is whenever a non-breaking change is added
that you want across all versions, you'd have to retrofit it into every
implementation.
I'm considering creating an abstract base implementation and inheriting
each concrete implementation from it along with its corresponding
interface, like this:

This allows me to keep the common code in a single place and only specific
changes in each concrete implementation.
Is there a reason I shouldn't do this? Is there a best practice or pattern
for handling service versioning architecture?

No comments:

Post a Comment