I am trying to come up with a way to wrap a very large web service that changes very frequently. There are 400+ types and each type has 20 to 300 attributes.

The service is a SalesForce.com Enterprise API.

Typically in this scenario I would create a corresponding domain model and interfaces and use AutoMapper or similar.

Due to the size and changeability of the web service, this approach would mean a maintainability nightmare... T4 to the resuce?

Unfortunately not - the types that are generated from the web service do not tie-up nicely! There are areas where the auto-generation could not determine the object types.

Wherever a type has a property that represents a collection of other objects, instead of producing an IEnumerable<SomeType> it generates a SalesForceQueryObject - so there is no way for me to determine the actual type that the collection contains.

Does anybody have a way to encapsulate this monster, that doesn't involve hand-cranking and maintaining 100's of thousands of lines of code? The code that is generated for the service reference is currently 347,000 lines long

  • 2
    consider establishing Anti-Corruption layer to protect your code from monster and using XSLT to additionally isolate changes in their data format
    – gnat
    Jan 13, 2014 at 14:37
  • 1
    Thanks gnat, that's exactly what I had in mind, although much better solved by the Anti-Corruption Layer pattern, unfortunately doesn't get away from having to code all the entities by hand... That being said, posting this question has forced me to come to terms with the inherent problem with the service generated classes; and forced me to come to terms with the fact that there is no other way than to hand-code the mirror classes. I'll have to take the maintenance hit, as distributing the dependency on the web service classes throughout the solution is not an option.
    – RobD
    Jan 13, 2014 at 16:18


Browse other questions tagged or ask your own question.