Implementation Guidelines for GetProperty

This post is just some quick thinking about guidelines for implementing the GetProperty method. These guidelines are still in development so think of this as a draft rather than real guidance at this time.

Background: We provide an extensibility point called GetProperty on many of the components you can build using the channel model. The exact list of components that support GetProperty are bindings, binding elements, channel factories, channel listeners, channels, and message encoders. GetProperty allows someone to execute a strongly-typed query against your component to inspect its configuration settings. GetProperty takes a type parameter T and either returns some instance of T or returns default(T) to indicate that the type is unknown.

DO expose configurable settings for your component using GetProperty. GetProperty should be used in preference to ad-hoc methods for searching through a stack of components.

DO NOT require the use of GetProperty to access mandatory or intrinsic configuration settings. The types supported by GetProperty are not discoverable and any setting that your component considers mandatory should be accessible through the object model. GetProperty can be used as an alternative way of accessing the same value.

DO support in your runtime objects every property that was available on your design time objects. If a channel factory exposes a setting, then every channel produced by that factory should expose a corresponsing setting that tells you what the value was when the channel was created.

DO create specialized interfaces that capture each class of information that you want people to query on. Specialized interfaces promote the reuse of a particular type for semantically identical settings.

DO reuse existing interfaces if your information has exactly the same semantics as the previous use. Conversely, if your settings don't have the same semantics, don't reuse a type just because it's more convenient to do so.

DO NOT key properties off of commonly used types with a generic meaning. Types that appear frequently, such as IDisposable, will not have consistent semantics for all of their potential uses.

DO NOT key properties off of value or enumerated types. We enforce this by placing a restriction on the generic type parameter.

DO delegate down to inner channels, channel factories, and channel listeners when they exist and your component does not know about the requested type. We have a pipeline model that supports the composition of many components. If your component does not understand a type, then it should give others the chance to respond.

Next time: Datagram Transports

Comments

• Anonymous
  October 26, 2006
  Throughout much of WCF development, we tried to preserve some fundamental symmetries between the client

• Anonymous
  October 26, 2006
  The comment has been removed

• Anonymous
  November 02, 2006
  Another point about delegation: When you have a composable object (such as ISecurityCapabilities) you may want to get the delegated value (if any) and then compose your property with the delegated value so that the composite result actually represents the value from "the stack"

• Anonymous
  January 18, 2007
  I occasionally see people asking how they can fake the security capabilities of a binding. These questions

• Anonymous
  May 14, 2007
  I drew this picture for myself while working on the guidelines for implementing GetProperty . I figured

• Anonymous
  September 24, 2007
  The comment has been removed