Michele’s WCF Tips (2)

Here is a second dose of WCF tips, yeah, two blog posts in a row, I’m on a roll! Woo hoo!

Uh, yeah, I know, I have a lot of catching up to do on the blogging department.

• Assembly Allocation
  • At a minimum you will have separate assemblies for each logical group of services: data, business, and service assemblies
  • Contracts and Entities are also good logical assembly separations
  • Per logical group of services or shared if common
• Service Contracts
  • Naming
    • Always supply a Namespace for service contracts
    • Optionally supply a value for contract Name to reduce refactoring risk
      • That goes for service contract, operation contract, and message parameters
  • WSDL
    • Factor WSDL output carefully
    • Hide internal endpoints from external clients by creating separate services (use a common base service implementation
• Data Contracts
  • Don’t use POCO types, always apply data contract and data member attributes
  • Data members should be public to avoid confusion
  • In simple scenarios, use ServiceKnownType to specify hierarchy at the service contract tier
    • Apply ServiceKnownType to service contract, not the service type
  • In complex or more dynamic scenarios, use DataContractResolver
    • This really only applies to applications where derivations of a base type are added dynamically or the number of types is unmanageable to decorate the service contract
  • Explicitly provide IsRequired and Order for data members
    • For versioning and to clarify expectations on the wire
  • Optionally use data contract and data member Name to avoid refactoring issues
  • When you own both sides, use a shared library for data contract
• Message Contract
  • Use message contract for simple scenarios that require including headers in the WSDL
  • Use message inspectors to add headers programmatically when you own both sides, bury details in the proxy and ServiceHost initialization code
  • Avoid advanced features of message contract unless required by interop (protection level, wrapped/unwrapped messages)
  • Do not provide namespace to message contract elements unless required for interop (will inherit from ServiceContract)
• IXmlSerializable
  • Use IXmlSerializable when you must follow specific schema, do not use nasty object model produced by reverse engineering
  • Include wrapper type in contracts library, not with entities (part of service contract just like message contracts are)

Two down…more to come…cheers!