Contract-First Development

| | Comments (0) | TrackBacks (0)

I just started a project with a new team of developers who are using contract-first development when defining the data contracts of their services.  So, I am objectively reexamining this methodology and weighing it against its alternative – code-first development.

In doing so, I’ve seen that contract-first development has many compelling benefits.  It offers support for versioning, versatility, predictability, and interoperability to name a few.  Aaron Skonnard insightfully retells how these two approaches were used in COM development in his article Contract-First Service Development.  VB programmers, Skonnard explains, used code-first development to define the interfaces of their COM components which lead to versioning issues and incompatibility between their components and that of their C++ contemporaries.

The new group I’m working with is building their services using WCF.  When doing contract-first design with this new technology, it is the job of the DataContractSerializer (à la svcutil) to convert the contract from XML Schema into C# code.  This components places a number of restrictions on what parts of XML Schema are allowed in the data contract.  If these restrictions aren’t adhered to, svcutil will generate C# code that is (de)serialized by XMLSerializer which levies a purported 10% performance increase.*  When creating services in WCF, these restrictions and performance penalties limit the versatility that contract-first development can provide.

When using code-first development, some translation application has to convert the code into a language agnostic contract.  Reliance upon such an program can make the code-first developers susceptible to unpredictable results.  This dependency hurt VB developers at times, Skonnard further explains, because the auto-generated contract was suboptimal vis-à-vis interoperability.  When the output of a translation system isn’t carefully crafted with compatibility in mind, integration issues ensue.  Learning from this mistake, Microsoft developed the DataContractSerializer to be used as the default WCF serialization layer (rather than reusing XMLSerializer) for the sole purpose of generating interoperability contracts from CLR code.  As a result, its output is predicable and compatible with other Web service platforms.

Two other issues that should be factored in when choosing between contract- or code-first development are the level of expertise required to design contracts in XML Schema and the integration of the translation layer into the IDE used by developers.  While learning XML Schema isn’t hard, it's not something that many junior developers know, limiting productivity if they are required to learn it before defining their service contracts.  Also with regard to productively, Visual Studio 8 and 9 (beta 2) do not provide an integrated way to translate XML Schemas into CLR code that is (de)serialized with the new serializer.  Developers have to create a pre-build event that runs svcutil over their XSD file or manually invoke it from the command line.

Due to the interoperable nature of the DataContractSerializer, the limited skill set of junior developers, and the lack of integrated tool support in Visual Studio, I think that data contracts should be designed using code-first methods when working with WCF.

* Microsoft Windows Communication Foundation: Hands-on by McMurty, Mercuri, and Watling pg. 75.