y - Net Developer

CHAPTER 11 ■ WORKING WITH DATA 347ramrameshreddy.blog.comTable 11-1 summarizes the options available when changing a data contract and theimpact that change has on the consumers, if any.Table 11-1. Data Contract Change and Its ImpactChangeChanging name or namespaceChanging order of data membersRenaming data membersChanging data contractAdding data memberRemoving data memberImpact of ChangeBreaking changeBreaking changeBreaking changeBreaking changeNonbreaking change (in most cases)Nonbreaking change (in most cases)Changing contracts is a tricky situation no matter how careful you are. You can change thecontracts in many ways—by adding, removing, or modifying—and you can cause many issueson either end of the wire. These can include the obvious issues where an exception will bethrown (and it would be easier to debug and fix) to the more interesting ones where the datamay lack integrity and not make sense. Figure 11-2 shows a versioning decision tree that youcan use to see the effect of any changes applied to the data contracts. The versioning decisionsare depicted with blue diamonds, and the actions of those decisions are represented in rectangles.The arrows represent the direction of the flow. The green actions represent nonbreakingchanges, and those in orange show breaking changes.Let’s take an example service and walk through the flowchart. When you need to modifyyour existing service and can do so by adding a new service, then the easiest way forward is touse service contract inheritance. This new type will be pointing to a new endpoint, which onlythe new consumers of this service will be aware of; the existing consumers will continue usingthe existing published version of the service. However, if this is not an option and you need tochange the data contract, then (depending on the kind of change) this may or may not beeasy. If you need to add more data, then, as you can see in Figure 11-2, the easiest option isadding new optional data members.If adding new members is not an option and you need to change the service operationand its corresponding data contract, then, as shown in the decision tree, it is best to implementa new version of the data contract (depicted as “v.Next”) within a new namespace andalso pointing to a new endpoint. It is recommended that you incorporate a version number inthe namespace. At this point if you choose, you can deprecate the old endpoint, and it is thisaction of deprecating that is breaking. If you are only deleting a service operation, you cankeep the same data contract and just implement the “v.Next” version of the service and namespacepointing to a new endpoint.ramrameshreddyramrameshreddy