DI with auto-generated web service clients

Question

I'm trying to do dependency injection throughout the app tier and am running into a scenario I'm sure others have seen. There are some 3rd party web services that we consume and the clients were auto-generated with a base class. The clients do not have an interface and the data types are in the same file/project.

The obvious problem is if I want to do unit testing I'll need to mock the service. I'll need to extract an interface and move the data types into a "contracts" project that is available to both real/mock clients. However, the next time the client is auto-generated that work needs to be redone. Creating a proxy at runtime wouldn't help much because then we would have to manually create the interfaces and data types from the WSDL. Is there a better way to handle this?

Answer 1

Extracting an interface from the implementation is not going to help you much anyway, as it's going to be a poor abstraction.

Interfaces should be defined and owned by the clients that consume the interfaces. As Agile Principles, Patterns, and Practices explain, "clients […] own the abstract interfaces" (chapter 11). Thus, any attempt to define a data-centric interface like extracting interfaces from auto-generated web service clients is bound to cause problems sooner or later, because it's violating various SOLID principles like the Dependency Inversion Principle or the Interface Segregation Principle.

Instead, your client code should define the interfaces that they require. Then you can always implement those interfaces with the auto-generated web service clients. If you've used Microsoft's tooling (Visual Studio, wsdl.exe, etc.) the relevant auto-generated class should already be a partial class, which means you should be able to add behaviour to it without touching the auto-generated part of it.