Contract-First SOA with WCF

Question

This question is more of a probe to discover what people are doing in the community, in practical situations, than a specifically targeted question. I have searched pretty broad

Answer 1

In WCF, you have some diversity in what 'contract-first' looks like. You can do a 'code contract first' where your data and service contracts are expressed as .NET types with the right attribute markup. You can start with WSDL and generate the service and data contracts, or you can start with XML schema for your data contract, and express the service contract as code. Which way you go really depends on the nature of the contract and how it will be used.

If you're implementing something to a WSDL spec, code gen from WSDL is the obvious choice, and generating from hand is not such a big deal. You could trigger generation from a project build event (or get into msbuild) if you want changes to the WSDL file to propagate immediately.

If you have existing schema (XSD) that you want to use as a data contract, or prefer to develop your data contract that way for easier re-use in other platforms, you can generate types from schema using xsd.exe (or a 3rd party alternative). In this case, you would use your XML-serializable types in your code-oriented service contract like this: .

If you're developing the clients and servers yourself in .NET, and your clients can either get your contract assemblies or are happy generating clients from service metadata (e.g. WSDL), modeling your contracts in code is a great experience. Using the "known types" scheme, you can support inheritance models in your data contract, which can be very powerful. You can skip generating client code entirely (as mentioned in other replies) by directly referencing the contract assembly in your client. It's very productive and elegant, but you need to be aware that you can create interop challenges if you get too fancy.