Pragmatic Programmer

This situation of new-old-new interaction is called a versioning round-trip. WCF supports handling of versioning round-trips by allowing a service (or client) with knowledge of only the old contract to simply pass through the state of the members defined in the new contract without dropping them. The problem is how to enable services/clients that are not aware of the new members to serialize and deserialize those unknown members without their schemas, and where to store them between calls. WCF’s solution is to have the data contract type implement the IExtensibleDataObject interface

만약 Endpoint끼리 DataContract에 미스매치가 있을 경우를 대비해, 꼭 필요한 DataMember에 IsRequired=true 를 세팅한다. 그렇게 하면 콜 하다  NetDispatcherFaultException 익셉션이 발생한다.

Endpoint 사이의 메세지 직렬화때문에, 객체의 자동형변환이 가능하지 않다. 가능하게 하기 위해서는 명시적으로 derived 타입을 알려줘야 한다. The solution is to explicitly tell WCF about the Customer class using the KnownTypeAttribute, defined as: [AttributeUsage(AttributeTargets.Struct|AttributeTargets.Class, AllowMultiple = true)] public sealed class KnownTypeAttribute : Attribute { public KnownTypeAttribute(Type type); //More members } [AttributeUsage(AttributeTargets.Interface | AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = true)] public sealed class ServiceKnownTypeAttribute : Attribute { public ServiceKnownTypeAttribute(Type type); //More members } WCF lets you configure the known types in the service’s or client’s config file, as shown in Example 3-6. You need to provide not just the type names, but also the names of their containing assemblies. When not relying on string name or assembly version resolution, you can just use the assembly-friendly name: Or use Data Contract R...

When adding  a  service reference in Visual Studio 2010, you must provide a unique namespace for each service reference. The imported types will be defined in that new namespace. This presents a problem when adding references for two different services that share the same data contract, since you will get two distinct types in two different namespaces representing the same data contract. By default, however, if any of the assemblies referenced by the client has a data contract type that matches a data contract type already exposed in the metadata of the referenced service, Visual Studio 2010 will not import that type again. It is worth emphasizing again that the existing data contract reference must be in another referenced assembly, not in the client project itself. This limitation may be addressed in a future release of Visual Studio, but for now, the workaround and best practice is obvious: factor all of your shared data contracts to a designated class library, and ha...

Syntax aside, how do you go about designing service contracts?  How do you know which operations to allocate to which service contract?  How many operations should each contract have?  Answering these questions has little to do with WCF and a lot to do with abstract service-oriented analysis and design.

Service contract interfaces can derive from each other, enabling you to define a hierarchy of contracts. However, the ServiceContract attribute is not inheritable . Consequently, every level  in the interface hierarchy must explicitly have the  Service Contract attribute. And the host can expose a single endpoint for the bottommost interface in the hierarchy. 아항~