Design best practice: Re-Using data contracts on multiple tiers of WCF / SOAP Web Services RRS feed

  • Question

  • Hi All, 

    I'm struggling with a design decision in a solution I'm currently working on. The basic structure of the solution is as follows:

    - A presentation layer consisting of UIs on multiple device types (Web site, Mobile app, WAP, etc.) all of which communicate with the business layer through,

    - A single WCF web service (lets call it the Interface service) exposing the methods required by the UI apps. This, in turn communicates with,

    - A number of function-specific service adaptors, many of which also expose WCF web service interfaces. Each of these, in turn, communicate with,

    - Downstream systems, outside of the enterprise (and the scope of the solution). Many of these also expose web service interfaces (Standard SOAP or WCF)

    My design decision relates to the data contracts and objects exposed throughout the system. In some cases, the data contracts that will be exposed to the UI apps from Interface service will be identical in structure and signature to the data contracts exposed by the final downstream systems. This means that in some cases, we will have data contract classes 3 components of the system (Downstream systems, Service Adaptor and Interface Service) that are essentially identical. 

    At present, I am creating separate data contracts in the Service Adaptors and Interface Services that contain basically the same fields. I then create casting methods to manually cast from one to the other when required. Not only is this time-consuming but also strikes me as unnecessary / mistaken. I keep thinking to myself that there MUST be a better / faster / more 'correct' way of handling this type of situation

    So, in short, my question is; what is the 'correct' way of managing the data contracts in WCF services in the above scenario?

    I thank you in anticipation

    Saturday, July 27, 2013 7:58 AM

All replies

  • I don't mean this question to be inflammatory, a genuine question; if they are the same, what is the purpose of the different services?


    Sunday, July 28, 2013 7:50 AM
  • A fair question and one I asked myself when I was handed the project.

    The Interface service provides a single integrates interface into the system for the different types of UI. Now, in theory, this interface layer COULD communicate directly with the external downstream systems but it is just what it says, an Interface. There is some business logic implemented there but the bulk of the actual business logic is contained in the Service Adaptors, most of which already exist.

    In addition the Service Adaptors handle requests from a number of different upstream clients, my Interface service being just one of many. Obviously, the business layer has a number of additional functions to perform in addition to the ones managed in the Interface and these are completely hidden from the interface. the one Service Adaptor that is I need to build in my part of the project is a simple pass-through service but it it required that we follow the established architecture of having specific Service Adaptors to perform specific functions and communicate with specific downstream systems. 

    There are additional security considerations that mean that we cannot simply re-expose the Adaptor data contracts to the UI and thus the need for separate data contracts that essentially look the same

    Sunday, July 28, 2013 8:17 AM
  • Hmm sounds like most of the system constraints/design are looking pretty fixed with little scope to manoeuvre to a different design. IMO I would keep them separate, the design seems to be one of 'what-if' in terms of how different components may in the future interact. Since that seems set in stone I would continue with that style and say, 'what if' we needed a different data contract between layers. I.e. Just because they're the same now doesn't mean that won't be later.

    FYI If I could I would have urged to go with a Service Bus pattern here, but I just don't think you want to hear that now :)


    Sunday, July 28, 2013 9:00 AM