Here is a second dose of WCF tips, yeah, two blog posts in a row, I’m on a roll! Woo hoo!
Uh, yeah, I know, I have a lot of catching up to do on the blogging department.
- Assembly Allocation
- At a minimum you will have separate assemblies for each logical group of services: data, business, and service assemblies
- Contracts and Entities are also good logical assembly separations
- Per logical group of services or shared if common
- Service Contracts
- Always supply a Namespace for service contracts
- Optionally supply a value for contract Name to reduce refactoring risk
- That goes for service contract, operation contract, and message parameters
- Factor WSDL output carefully
- Hide internal endpoints from external clients by creating separate services (use a common base service implementation
- Data Contracts
- Don’t use POCO types, always apply data contract and data member attributes
- Data members should be public to avoid confusion
- In simple scenarios, use ServiceKnownType to specify hierarchy at the service contract tier
- Apply ServiceKnownType to service contract, not the service type
- In complex or more dynamic scenarios, use DataContractResolver
- This really only applies to applications where derivations of a base type are added dynamically or the number of types is unmanageable to decorate the service contract
- Explicitly provide IsRequired and Order for data members
- For versioning and to clarify expectations on the wire
- Optionally use data contract and data member Name to avoid refactoring issues
- When you own both sides, use a shared library for data contract
- Message Contract
- Use message contract for simple scenarios that require including headers in the WSDL
- Use message inspectors to add headers programmatically when you own both sides, bury details in the proxy and ServiceHost initialization code
- Avoid advanced features of message contract unless required by interop (protection level, wrapped/unwrapped messages)
- Do not provide namespace to message contract elements unless required for interop (will inherit from ServiceContract)
- Use IXmlSerializable when you must follow specific schema, do not use nasty object model produced by reverse engineering
- Include wrapper type in contracts library, not with entities (part of service contract just like message contracts are)
Two down…more to come…cheers!
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 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)
- 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)
- 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
- You will always customize standard bindings
- Message and reader quotas
- 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
- 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
- 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 )!
For some time now I have had time sucked out of my day, minutes at a time, every time I wanted to click a link to download or open and run a file from IE 9. It has been driving me nuts, almost literally.
The problem is that Open and Run commands in this discreet download toolbar stopped working at some point. It would tell me that the item downloaded and then the toolbar disappears before I can click it to open the file folder even.
I googled, I binged, but I could not find a solution to the issue. In a last ditch attempt before switching to another default browser I emailed my RD fiends and thanks to Mr. Scott Seely found the answer. Thought I would share in case others see this issue.
Scott said in his email to me:
This worked, thank you Scott and hopefully this can be found by other googling, binging, frustrated people with the same problem.