Essentials

  1. Place service code in a class library, not in any hosting EXE.

  2. Do not provide parameterized constructors to a service class, unless it is a singleton that is hosted explicitly.

  3. Enable reliability in the relevant bindings.

  4. Provide a meaningful namespace for contracts. For outward-facing services, use your company’s URL or equivalent URN with a year and month to support versioning. For example:

    [ServiceContract(Namespace = "http://www.idesign.net/2010/09")]
    interface IMyContract
    {...}

    For intranet services, use any meaningful unique name, such as MyApplication. For example:

    [ServiceContract(Namespace = "MyApplication")]
    interface IMyContract
    {...}
  5. With intranet applications, prefer self-hosting to IIS hosting when the WAS is unavailable.

  6. Do not mix and match named bindings with default bindings. Either have all your bindings be explicitly referenced, or use only default bindings.

  7. Do not mix and match named behaviors with default behaviors. Either have all your behaviors be explicitly referenced, or use only default behaviors.

  8. Always name all endpoints in the client config file.

  9. Do not use SvcUtil or Visual Studio 2010 to generate a config file.

  10. When using a tool such as Visual Studio 2010 to generate the proxy, do clean up the proxy.

  11. Do not duplicate proxy code. If two or more clients use the same contract, factor the proxy to a separate class library.

  12. Always close or dispose of the proxy.

  13. When using discovery, prefer dynamic addresses.

  14. When using discovery, do support the metadata exchange ...

Get Programming WCF Services, 3rd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.