Tuesday, May 20, 2008 - Posts

• LINQ don't stink

  Recently, I had to write a test case that posed an interesting problem. The product that I am working, Identity Lifecycle Manager "2" uses the concept of sets. Sets are defined by XPath filter expressions. When a user submits a request to create, read, update or delete a resource, then that resource, as well as associated resources, may transition into or out of any number of sets. We have a Request type for representing user's requests, and when we determine the set transitions that will result from a request, we add the information about those set transitions to the Request object. Each set transition is represented by a piece of XML that looks roughly like this: <SetTransition> <ResourceIdentifier>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</ResourceIdentifier> <SetIdentifier>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</SetIdentifier> <Join>1</Join> <Leave>0</Leave> </SetTransition> A Request object has a SetTransition property of the ReadOnlyCollection<string> type, with each string in the collection being an XML representation of a set transition. We don't have to reason about the set transitions programmatically any further in our C# code, so it suffices that they are exposed as strings of XML, rather than as strongly-typed objects. Now, in my test case, I create a Request, dip it into the part of our request processor that figures out the set transitions, and then decide whether it calculated the set transitions correctly. It should be apparent that deciding whether the set transitions were calculated correctly is a matter of querying a .NET collection of strings of XML, to determine whether that XML contains the correct data. As a general solution for querying data of any sort, LINQ seemed to be the appropriate tool for the job, and that did turn out to be the case. Specifically, it was possible for me to craft my test so that I could ask, in a single statement, whether the transitions of two particular resources into two particular sets was detected: var count = ( from document in ( from item in request.SetTransitions select XDocument.Parse(item) ) where ( ( //There is a transition to or from the set. ( from element in document.Descendants() where ( ( ( string .Equals(element.Name.ToString(), "SetIdentifier" , StringComparison.Ordinal)) && ( string .Equals(element.Value, setIdentifier.GetGuid().ToString(), StringComparison.Ordinal)) ) ) select element ).Count() == 1 ) && ( //The transition Read More... Posted Tuesday, May 20, 2008 7:53 PM from Craig McMurtry's WebLog | 0 Comments

• Avoid Exceptions in Faults

  FaultException supports both an untyped variant, for when you don't have any particularly interesting detail to provide, and a typed variant, for when you do. Don't use a subclass of Exception as the type of a typed FaultException. Here's why. When you use a typed FaultException, you are creating a fault contract between the client and service about data that gets exchanged and a common type system that the two share. By using a CLR exception type, you are unnecessarily forcing that common type system to reflect details of the CLR type system. That type dependency will make it more complicated in the future to move your services and clients to other platforms and possibly even to other versions of the framework. When moving to another version of the framework, you may change the exception profile of your application and start receiving exception types that are more specific or different than the exception types that you received before for a particular error. If you pass those exceptions through to the client, then those platform implementation details are now leaked across the service boundary. Finally, there's no guarantee that the interesting information in a CLR exception will be preserved across the boundary. Most of the interesting contents of exceptions are not serializable. Instead of creating a FaultException with a subclass of Exception, you should define a fault contract that is meaningful for your application or business user. This fault contract can be crafted according to the needs of your service and will remain independent of any particular platform or technology choices that you may need to make later. Next time: Faster Known Types in Orcas Read More... Posted Tuesday, May 20, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Service Architecture, Faults