As I am teaching our IDesign WCF Master Class in Brussels this week, I thought I would post some a simple summary of WCF tips that come to mind as we cover the vast landscape of WCF features. Here’s the first drop of tips to kick us off, enjoy! 
- SOA
- SOA is a good thing, service tiers are good for reuse but don’t overdo it.
- Try to keep to 2-3 service calls in single round trip (usually 2)
- Addressing
- Never hard code base address or endpoint address
- Provide base address in configuration
- Even better, use runtime configuration to simplify managing web farm configuration (custom code required)
- Hosting
- Use console host for initial testing unless hosting in IIS/WAS and this is available locally
- Always test in “real” hosting environment as well
- Try to use WAS with AppFabric whenever possible
- Use AppFabric for auto-start and visibility to exceptions (prefer custom diagnostics to centralize warnings, exceptions, debug and information trace logs)
- Windows services are useful for unknown deployment environments
- Using statement
- Ok for test hosts (console) since app domain shutting down
- Not ok for most other self-hosting environments (Windows service, worker role, windows client) so you must decouple Close() and on exception call Abort() to clean up resources
- Never use “using” for proxies
- You will typically provide a custom host for common behavior and endpoint initialization
- Requires a ServiceHostFactory for IIS/WAS endpoints
- Bindings
- You will always customize standard bindings
- Message and reader quotas
- Security
- You will often need <customBinding>
- To provide specific features not exposed by standard bindings
- Complete your overall system design first, then establish a pattern for bindings
- Includes security model
- You’ll likely come up with 2-3 bindings used throughout clients/services and other tiers
- Wrap these into reusable Binding types to be called at runtime or configured with custom configuration section
- Share binding code between clients and services (unless you can’t)
- Client version may differ slightly
- Endpoints
- Store endpoint requirements in shared code for both client and service if you own both sides
- dynamic aspects such as base address will come from respective configuration files
- Initialize endpoints programmatically (custom ServiceHost and proxy initialization code)
- Good for web farms, reduce effort to update multiple servers on change
- Not required for Windows Azure but still useful
- Proxies
- Use proxy generation only for testing or clients that don’t share your components
- Create a separate shared library for contracts (service contracts, message contracts, fault contracts) and entities (data contracts, custom serialization code)
- Always Close() explicitly and Abort() on exception
- Not likely to use ClientBase<T>, more control over channel factory and channel
More tips coming tomorrow (she says assuming jet lag doesn’t take over 
)!