Under The Influence(of code)

Sunday, January 10, 2010

Covariance and Contravariance in C# 4.0

C# 4.0 introduces the notion of Covariance and Contravariance of generic type parameters for interfaces and delegate types. Eric Lippert has put together a bunch of posts that goes into details of the why and how, an excellent read but not for the faint of heart. I would strongly suggest reading these posts to get a firm grounding and a better appreciation of this feature. It took me a while to get my head wrapped around this, especially since none of the VS2010 Betas were not out at the time and there was no way to try out any code. Now that I have Beta2 of VS2010 at hand I decided to try out some code samples first hand and solidify my understanding of the feature.

Suppose we have the following inheritance hierarchy:

interface IAnimal
{
void Speak();
}
class Whale : IAnimal
{
public void Speak()
{
Console.WriteLine("I'm a Whale");
}
}
class Giraffe : IAnimal
{
public void Speak()
{
Console.WriteLine("I'm a Giraffe");
}
}

and a processor to process animals:

interface IProcessor<T>
{
void Process(IEnumerable<T> ts);
}
class Processor<T> : IProcessor<T> where T:IAnimal
{
public void Process(IEnumerable<T> ts)
{
foreach (var t in ts)
{
t.Speak();
}
}
}

It would be natural to be able to create a Processor to process any kind of animal, but the following code does not compile today on the C# 3.0 compiler

List<Giraffe> giraffeList = new List<Giraffe> { new Giraffe() };
IProcessor<IAnimal> proc = new Processor<IAnimal>();
proc.Process(giraffeList);

We have to add a silly"OfType<IAnimal>" cast to make it work:

List<Giraffe> giraffeList = new List<Giraffe> { new Giraffe() };
IProcessor<IAnimal> proc = new Processor<IAnimal>();
proc.Process(giraffeList.OfType<IAnimal>());

In C# 4.0 no such cast is needed and everything just works as expected. Why? because in .NET 4.0 IEnumerable<T> is covariant in it's type parameter T, this is what the definition looks like

public interface IEnumerable<out T> : IEnumerable
{
....
....
}

The "out" keyword is what makes the "T" covariant; which means that you can pass in any type which is more derived than "T" as the type argument, hence we can pass in IEnumerable<Giraffe> or IEnumerable<Whale> to the Process method which accepts an IEnumerable<IAnimal> and everything just works as expected in a type safe way.

You can define your own covariant types to allow for such conversions.
Consider the following generic class definition to create instances of a specified type

interface IFactory<out T>
{
T CreateInstance();
}
class Factory<T> : IFactory<T> where T: new()
{
public T CreateInstance()
{
return new T();
}
}

IFactory<T> is covariant in T so we can treat a Factory<Giraffe> as an IFactory<IAnimal>. This allows us to treat factories of types in the same inheritance chain uniformly like so:

IFactory<IAnimal> giraffeFactory = new Factory<Giraffe>();
IFactory<IAnimal> whaleFactory = new Factory<Whale>();
List<IFactory<IAnimal>> factories = new List<IFactory<IAnimal>>{ giraffeFactory, whaleFactory };
foreach (var factory in factories)
{
factory.CreateInstance().Speak();
}

Note that it is illegal for a covariant type parameter to occur in an input position, it can only occur in output positions such as return type of a method in the type. This restriction is key in making covariance work,allowing the type parameter in an input position would break covariance. How you might ask. Imagine if the following illegal code were legal and you could specify T in an input position.

interface IFactory<out T>
{
T CreateInstance();
T CreateInstanceFrom(T t);
}
class Factory<T> : IFactory<T>
where T : new()
where T : ICloneable
{
public T CreateInstance()
{
return new T();
}
public T CreateInstanceFrom(T t)
{
return (T)t.Clone();
}
}

We added a constraint to the factory class to constrain the type parameter to support ICloneable and added a new method CreateInstanceFrom which accept the instance to clone. Now what happens if we do the following:

IFactory<IAnimal> giraffeFactory = new Factory<Giraffe>();
giraffeFactory.CreateInstanceFrom(new Whale())

Oh my! we just passed in a Whale to clone a Giraffe, and we'd bomb a runtime.
It is precisely for this reason that a covariant type parameter can only occur in output positions(hence the keyword out) and the runtime error is now a compile time error.

But what if we wanted to have the type paramter in an input position to get the benefits variance has to offer, enter contrvariance which is the dual of covariance. In that a type argument can be safely replaced by a more derived type but only in an input position.

If T appears ONLY in an input position (such as a parameter in methods of IProcessor) then we can mark T as contravariant using the in keyword, allowing us to substitute any sub type of T.

interface IProcessor<in T>
{
void Process(IEnumerable<T> ts);
}

This makes assignments such as the following legal.

List<Giraffe> giraffes = new List<Giraffe> { new Giraffe() };
List<Whale> whales = new List<Whale> { new Whale() };
IProcessor<IAnimal> animalProc = new Processor<IAnimal>();
IProcessor<Giraffe> giraffeProcessor = animalProc;
IProcessor<Whale> whaleProcessor = animalProc;
giraffeProcessor.Process(giraffes);
whaleProcessor.Process(whales);

Finally let's look at variance in delegate types. Consider the following delegate definition and it's subsequent usage

public delegate void MyAction<in T>(T t);
........
.......
.........
MyAction<IAnimal> animalAction = a => a.Speak();

Since T is contravariant, we can treat MyAction<IAnimal> as MyAction<Giraffe> since Giraffe is more derived than IAnimal

MyAction<Giraffe> rafAction = animalAction;

Now let's combine both co and contravariance, consider the following delegate

public delegate T2 MyFunc<in T1,out T2>(T1 t1);

T2 is covariant and T1 is contravariant and hence we can use T1 or any subtypes of T1 as the first generic type paramter and T2 or any of its base types as the second generic type parameter, allowing us to use assignments such as the following with full type safety

Func<IAnimal, Giraffe> func = a => a as Giraffe;
Func<Giraffe, IAnimal> funcG = func;

Covariance and Contravariance may sound like a mouthful and daunting to understand but at its core it's quite simple to grasp once you understand its purpose, it enables writing generic code more naturally and allows safe type coercions. That's it for today. Happy coding.

posted @ Sunday, January 10, 2010 12:50 PM | Feedback (2)

Sunday, October 18, 2009

T4 template consuming a WCF service

It’s been a while since I’ve blogged and but I have a valid excuse; I moved to WA state recently and things have been crazy busy. I finally decided to kick myself and do a post so without further ado, the problem at hand:
A co-worker of mine asked me whether its possible to dynamically create a type from some data he is receiving from a WCF service (over HTTP).
My natural response was, why would you need to do that since Visual Studio creates a proxy from the metadata exposed by the service and the return types would typically be DataContracts.
Well, it turns out that instead of returning a strongly typed domain specific object, the service is returning a Dictionary<string,string> where the Key represents an attribute and the Value represents the value of the attribute.

This has obvious problems:

Nothing is strongly typed
No contract versioning
The service could return a variable number of fields

A naive approach is to inspect the data returned by the service and hand code a class with properties based on the type of each key in the Dictionary.
For example, if the Dictionary contained the following KeyValuePairs.
{“Name”,”Jon Smith”}
{“Age”,”20”}
{“Zip”,”90876”}

The class definition would look something like this:

public class User
{
public string Name {get;set;}
public int Age {get;set;}
public int Zip {get;set;}
}

That’s fine when you have a couple of KeyValuePairs but what if you had 10 or 20, it gets unwieldy very quickly.
Enter T4 templates, a slick way to generate code for repetitive tasks. I'd never written a T4 template before so I figured this would be a nice excuse to dabble in it a little.

Let’s create a simple service to simulate some data, nothing too fancy

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace T4WCFService
{
[ServiceContract]
public interface IT4WCFService
{
[OperationContract]
Dictionary<string,string> GetUser(string userID);
}
}

and its implementation...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace T4WCFService
{
public class T4Service : IT4WCFService
{
#region IT4WCFService Members
public Dictionary<string, string> GetUser(string userID)
{
if (userID == "jsmith")
{
return new Dictionary<string, string>
{
{ "Name", "Jack smith" },
{ "Age", "30" },
{ "City", "San francisco" },
{ "State", "CA" },
{ "Zip", "94061" },
{ "Country", "USA" }
};
}
if (userID == "jasmith")
{
return new Dictionary<string, string>
{
{ "Name", "Jane smith" },
{ "Age", "28" },
{ "City", "Portland" },
{ "State", "OR" },
{ "Zip", "98685" },
{ "Country", "USA" }
};
}
return new Dictionary<string, string>();
}
#endregion
}
}

The service just simulates returning some dummy users based on a userID and returns an empty Dictionary if no matching user is found, and it’s exposed using

WSHttpBinding

The <system.servicemodel> looks as follows:

<system.serviceModel>
<services>
<service behaviorConfiguration="T4WCFService.Service1Behavior"
name="T4WCFService.T4Service">
<endpoint address="WsHttpT4Service" binding="wsHttpBinding" name="WsHttpT4Service"
contract="T4WCFService.IT4WCFService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<endpoint address="basicHttpTService" binding="basicHttpBinding"
name="basicHttpTService" contract="T4WCFService.IT4WCFService" />
<host>
<baseAddresses>
<add baseAddress="http://WCFServices" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="T4WCFService.Service1Behavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

If you(like me) have never created a T4 template before, I’d strongly suggest reading this article first.

Welcome back, now that you know how to create a simple T4 template, let’s get started.
T4 enables writing reusable modules that can be consumed from other T4 modules. For the purpose of this exercise I decided to create a template which encapsulates invoking a WCF service and returning the result back to the caller.

Create a new Console Application and add a service reference to the service we created above, also add a new T4 file to your project called WCFServiceInvoker.tt

T4_WCFServiceInvoker

Double click on WCFServiceInvoker.tt and the file should open up in markup mode.Delete the default code in the .tt file and add the following code:

<#@ template language="C#v3.5"#>
<#@ output extension=".cs"#>
<#@ assembly name ="System.ServiceModel" #>
<#@ import namespace="System.Collections.Generic"#>
<#@ import namespace="System.Reflection"#>
<#@ import namespace="System.ServiceModel.Channels"#>
<#@ import namespace="System.ServiceModel"#>
<#+
public class WCFServiceInvoker<TInterfaceType,TReturnType> where TReturnType:class
{
public string EndPointAddress {get;set;}
public string EndPointName {get;set;}
public Type ServiceInterfaceType {get;set;}
public Binding Binding {get;set;}
public string MethodName {get;set;}
public object[] Parameters {get;set;}
public TReturnType InvokeMethod()
{
EndpointAddress endpoint = new EndpointAddress(EndPointAddress);
Type typeDef = typeof(ChannelFactory<>).MakeGenericType(typeof(TInterfaceType));
var typeInst = Activator.CreateInstance(typeDef,new object[]{Binding,endpoint});
var channel = typeInst.GetType().InvokeMember("CreateChannel", BindingFlags.InvokeMethod,null, typeInst, null);
var results = channel.GetType().InvokeMember(MethodName, BindingFlags.InvokeMethod, null,channel, Parameters);
return results as TReturnType;
}
}
#>

There is a lot going on here.

The template and output directives indicate that the code is written in C# and the generated file needs to be have an extension of .cs.
The <#@assembly> directive is similar to an “Add Reference” in Visual Studio, it allows for referencing external assemblies.
The <#@import> directive is similar to a “using” statement, in that it brings the types in the specified namespace in scope so that the template can avail of them.
The <#+ #> directive is called Class feature block and it allows for writing class definitions within the template.
This allows for encapsulating reusable logic.
NOTE: The class definitions in this block are not emitted out to the final .cs file.
The WCFServiceInvoker class contains a bunch of properties, whose values(when set) are used for invoking a specified service dynamically.
The type parameters “TInterfaceType” represents the type of the interface on which the method specified in the "MethodName" parameter will be invoked.
The type parameter “TReturnType” represents the type of the result returned from the method call.

Using “TInterfaceType” we dynamically create a type definition for ChannelFactory<T> using reflection, and then create an instance of it, on which we then call CreateChannel which in turns returns us an instance of a type which implements TInterfaceType. Once we have a “TInterfaceType” instance we then go ahead and invoke the specified “MethodName” with the parameters specified in the “Parameters” object[] property and get the result back which is typed to “TReturnType” and returned to the caller.

Phew! that’s a mouthful and we are not done yet. For now just keep in mind that this template is merely a helper which encapsulates the details on dynamically invoking a WCF service in a strongly typed manner.

Now onto the main task of writing a template to solve our problem.

Add another T4 template to the project and call it UserClass.tt
T4_UserClass

As before delete the code from the .tt file and add the following:

<#@ assembly name ="System.ServiceModel" #>
<#@ assembly name ="T4WCFService.dll" #>
<#@ assembly name ="System.ServiceModel" #>
<#@ import namespace="System.Collections.Generic"#>
<#@ import namespace="System.Reflection"#>
<#@ import namespace="System.ServiceModel.Channels"#>
<#@ import namespace="System.ServiceModel"#>
<#@ import namespace="T4WCFService"#>
<#@ include file="WCFServiceInvoker.tt" #>
using System.Collections.Generic;
namespace T4ClassFromDict
{
public class User
{
<#
WCFServiceInvoker<IT4WCFService,Dictionary<string,string>> invoker = new WCFServiceInvoker<IT4WCFService,Dictionary<string,string>>();
invoker.EndPointAddress = "http://localhost:24551/Service1.svc/WsHttpT4Service";
invoker.EndPointName = "WsHttpT4Service";
invoker.ServiceInterfaceType = typeof(IT4WCFService);
invoker.Binding = new WSHttpBinding();
invoker.MethodName = "GetUser";
invoker.Parameters = new object[]{"jsmith"};
Dictionary<string,string> result = invoker.InvokeMethod();
#>
<#foreach(KeyValuePair<string,string> item in result){
#>
public <#= item.Key.GetType().Name.ToLower()#> <#=item.Key#>
{
get;
set;
}
<#}#>
public static User GetUser(Dictionary<string,string> dict)
{
var user = new User();
foreach(KeyValuePair<string,string> kvp in dict)
{
typeof(User).GetProperty(kvp.Key).SetValue(user,kvp.Value,null);
}
return user;
}
}
}

We've included the template file we created before so that we can reuse it to invoke any WCF Service.
We then proceed to create an instance of WCFServiceInvoker and set it's properties to invoke the WCF service we've created.
The result of "invoker.InvokeMethod()" is a Dictionary<string,string> which we then loop through creating public properties.

We use the type of the Key as the type of the property and the Key itself as the property name.

We've also created the definition of factory method which accepts a Dictionary<string,string> and returns a User object.

Note that we've added a direct reference to the service assembly in this template so that we can get a reference to IT4WCFService.
This is just to keep the example simple, ideally you would want to seperate the interface and implementation assemblies and have a reference to just the interface assembly.

T4 templates are executed typically when saved or by right clicking on the .tt file and selecting "Run Custom Tool".
Before running the template, ensure that the WCF service is up and running.

On running/saving the template, the following class definition is generated.

using System.Collections.Generic;
namespace T4ClassFromDict
{
public class User
{
public string Name
{
get;
set;
}
public string Age
{
get;
set;
}
public string City
{
get;
set;
}
public string State
{
get;
set;
}
public string Zip
{
get;
set;
}
public string Country
{
get;
set;
}
public static User GetUser(Dictionary<string,string> dict)
{
var user = new User();
foreach(KeyValuePair<string,string> kvp in dict)
{
typeof(User).GetProperty(kvp.Key).SetValue(user,kvp.Value,null);
}
return user;
}
}
}

A client can then use the generates class as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.IO;
using System.ServiceModel;
using T4WCFService;
using System.Reflection;
namespace T4ClassFromDict
{
class Program
{
public string Foo { get; set; }
static void Main(string[] args)
{
var client = new T4Service.T4WCFServiceClient("WsHttpT4Service");
var data = User.GetUser(client.GetUser("jsmith"));
}
}
}

NOTE: The console app hosting the project has a direct project reference to WCF service project since it needs the IT4WCFService definition. and since T4 engine is running inside Visual studio it locks the assembly, so rebuilding the WCF service after template generation does not work.
As mentioned previously the solution to this is to have seperate assemblies for the interface and service implementation.
Download Code

posted @ Sunday, October 18, 2009 12:06 AM | Feedback (7)

Monday, August 24, 2009

Why no Anonymous Iterators in C#

Yes I’m a language geek and yes the awesome Eric Lippert is my idol when it comes to anything C# and the CLR, I’ve been following his blog for a long time and recently Eric wrote an awesome series on the how and why of Iterator Blocks. The entire series is very well worth a read, but then again I’d read almost anything Eric writes from why the sky is blue to why the Falkirk Wheel has horns.

I had posed a question on this post about why there are no anonymous iterators in C#. Eric provided a very good answer to that comment and I was highly flattered when he did a follow up post on this very question here.

Thanks Eric!

posted @ Monday, August 24, 2009 9:55 PM | Feedback (0)

Sunday, August 23, 2009

Creating Higher Level APIs with TPL

The BCL has a bunch of APIs which provide asynchronous versions of operations in the form of either Beginxxx/Endxxx or XyzCompleted, the former known as Asynchronous Programming Model(APM) and the latter known as Event Based Asynchronous Pattern (EAP). TPL provides a nice abstraction for performing asynchronous operations as Tasks using delegates, but what can you do for working with these existing BCL classes which already have an async version?

Here is an example.
Let's say we need to download some data from the web and save it to a file, you would typically use the WebClient class and write something like this today (wrapped in a method of course)

WebClient client = new WebClient();
client.DownloadDataAsync(new Uri("http://www.bing.com"));
client.DownloadDataCompleted += new DownloadDataCompletedEventHandler((s, e) =>
{
if (e.Error != null)
{
throw e.Error;
}
if (!e.Cancelled)
{
using (FileStream fs = new FileStream("bing.htm", FileMode.CreateNew))
{
fs.Write(e.Result,0,e.Result.Length);
fs.Flush();
fs.Close();
}
}
}
);
Console.Read();

Yuck not very pretty is it! It's kinda smelly and looking at the code, it doesn't really capture the essense of what we are trying to do, besides if the client were to call a method which does this work, we'd have to ensure that the client thread blocks till the continuation completes or conversely provide a mechanism such as a WaitHandle that the client can wait on, not very expressive is it?

Let's see how we can achieve the same results using the Task API.

private static TaskCompletionSource<byte[]> CreateSource(object state)
{
return new TaskCompletionSource<byte[]>(state);
}
private static void SetCompletionSource<T>(
TaskCompletionSource<T> tcs,
AsyncCompletedEventArgs e,
Func<T> getResult)
{
if (e.UserState == tcs)
{
if (e.Cancelled)
tcs.TrySetCanceled();
else
if (e.Error != null) tcs.TrySetException(e.Error);
else
tcs.TrySetResult(getResult());
}
}
public static Task<byte[]> DownloadBytesTask(this WebClient webClient, string uri)
{
var source = CreateSource(uri);
DownloadDataCompletedEventHandler handler = null;
handler = (object s, DownloadDataCompletedEventArgs e) =>
{
SetCompletionSource(source, e, () => e.Result);
webClient.DownloadDataCompleted -= handler;
};
webClient.DownloadDataAsync(new Uri(uri), source);
webClient.DownloadDataCompleted += handler;
return source.Task;
}

We've wrapped up the async network operation into a Task as an extension method.
Let's dig in a little...

In DownloadBytesTask, we first create a TaskCompletionSource which provides a mechanism to create a Task to hand out to consumers such that the only legal state modification to the Task can be performed via the methods available on the TaskCompletionSource itself and not on the instance of the Task directly, this is precisely the behavior needed for a Task that is downloading content from the web asynchronously;it doesn't make sense for the client to explicitly start such a Task which has already started downloading data and such an operation should really be considered illegal, TaskCompletionSource enables this behavior.

In the callback we call SetCompletionSource which is responsible for transitioning the state of the Task based on the results of the asynchronous operation such as whether it errored out, or completed or whether it was cancelled.

We then proceed to start the asynchronous download by calling DownloadDataAsync method of the WebClient instance.

Couple of things to note:

The callback has been unhooked from the event in the callback to ensure that we don't have a memory leak.
The Task has already started since "DownloadDataAsync" has already been invoked, and it is this started Task that we return from the method.

The client can now perform the asynchronous download and saving of content like so:

public class Program
{
public static Task WriteToFileTask(string fileName, byte[] bytes)
{
FileStream fs = new FileStream(fileName, FileMode.CreateNew);
var task = Task.Factory.FromAsync(fs.BeginWrite, fs.EndWrite, bytes, 0, bytes.Length, null);
return task;
}
static void Main(string[] args)
{
WebClient wc = new WebClient();
var task = wc.DownloadBytesTask("http://www.bing.com/");
var continuationTask = task.ContinueWith(a => WriteToFileTask("bing.htm", a.Result));
continuationTask.Wait();
}
}

The DownloadBytes extension method on the WebClient returns a Task which has already started, we then specify a continuation to execute "after" the Task completes by calling the "ContinueWith" method on the Task instance which in this case is itself a Task which works on the result of the antecedent task (a byte[]) obtained by calling the "WriteToFileTask" method which is responsible for writing out the byte[] to a file.

It's important to note that we have to wait for the "continuation" to complete by calling continuationTask.Wait(), otherwise the process will terminate since we are running on a console app. The same would hold true in case of a Webforms client since the calling Page would continue processing and not wait for the Task to complete.

Notice how the client code seems pretty terse in terms of expressing the intent. One can easily read the code and figure out what's going on.
As always happy coding!

posted @ Sunday, August 23, 2009 3:46 PM | Feedback (0)

Sunday, August 16, 2009

CLR via C# 3rd Edition

Some book news…Jeff Richter is one of my favorite authors and I’ll read just about anything he writes. His last book CLR via C#, 2nd Edition left me wanting more, luckily Jeff has signed into a contract for writing a 3rd edition of the book updated for C#3.0/4.0 and .NET 4.0

posted @ Sunday, August 16, 2009 3:06 PM | Feedback (0)

Thursday, July 23, 2009

Retrieving Added Entities from the ObjectStateManager to avoid duplication

Let's say we neede to process a bunch of entities coming from an XML file, create EDM entites for each XML element and eventually persist them. Very trivial to accomplish using a little bit of LINQ.

<Roles>
<Role name="Admin"/>
<Role name="Reader"/>
<Role name="Writer"/>
</Roles>

var doc = XDocument.Load("Roles.xml");
var roles = doc.Element("Roles").Elements("Role").Select(x => new Role { RoleName = (string)x.Attribute("name") });
PermissionsAPIContext context = new PermissionsAPIContext();
foreach (var role in roles)
{
context.AddToRoleSet(role);
}
context.Savechanges()

But wait, let's make this a little interesting...

<Roles>
<Role name="Admin"/>
<Role name="Reader"/>
<Role name="Writer"/>
<Role name="Reader"/>
</Roles>

See the problem now? If we process the above XML using the code from before, we end up adding the same entity twice!
So what do we do now?
ObjectStateManager to the rescue, let's rewrite the piece of code as follows:

var doc = XDocument.Load("Roles.xml");
var roles = doc.Element("Roles").Elements("Role").Select(x => (string)x.Attribute("name"));
PermissionsAPIContext context = new PermissionsAPIContext();
foreach (var role in roles)
{
Role roleEntity = GetRole(role, context);
if (roleEntity.EntityState == EntityState.Added || roleEntity.EntityState == EntityState.Detached)
{
context.AddToRoleSet(roleEntity);
}
}
context.SaveChanges();
private static Role GetRole(string roleName,PermissionsAPIContext context)
{
//NOTE: we could have used string.Compare(r.RoleName,roleName,true) == 0 inside the body of the lambda as a cleaner
//way to do this but this translates to some pretty snarly and inefficient SQL!
var roleEntity = context.RoleSet.FirstOrDefault(r => r.RoleName.Trim().ToLower() == roleName.Trim().ToLower());
if (roleEntity == null)
{
var stateEntries = context.ObjectStateManager.GetObjectStateEntries(EntityState.Added | EtityState.Modified | EntityState.Unchanged);
var roleEntityEntries = stateEntries.Select(s => s.Entity).OfType<Role>();
roleEntity = roleEntityEntries.FirstOrDefault(r => r.RoleName.Trim().ToLower() == roleName.Trim().ToLower());
if (roleEntity == null)
{
return new Role { RoleName = roleName };
}
}
return roleEntity;
}

A few of things note worthy here
1) In GetRoles() we first query the ObjectContext to check whether there is already a role present with the given name, if so we
simply return a reference to the existing entity instance
2) If the role is not existing then we check to see whether a role with the given name was added to the context, if so then we just
get a handle to this previously added(but not yet persisted) role and return that.
3) If the role is not existing and was not added previously then we create a new Role entity and return.
4) The caller checks whether the returned entity is an existing one and if not it's added to the ObjectContext.

After we are done processing all entities, we save all entities and we are done.

The above mechanism allows us to safely sidestep duplicates while processing based on some equality rule(which in this case happens to be the role name).

Hope this helps.

posted @ Thursday, July 23, 2009 1:41 AM | Feedback (1)

Friday, July 17, 2009

Inside TPL video

No code today. Instead, here is a link to a great video from Channel9 I found, which takes a deep dive into the underlying mechanics of how TPL does what it does and some of the enhancements that the thread pool has undergone. Albeit a year old, this video goes into details of the work stealing algorithm and local thread queues that helps increase throughput.

From the perspective of being a consumer of TPL, you can be blissfully ignorant of what happens behind the scenes, but understanding the mechanics and some of the design decisions that the team made can help gain a deeper appreciation of TPL which ultimately can help write more thoughtful code.

I was impressed by the clarity in which the concepts were presented and explained. Plan on setting aside about an hour to watch this video, but every minute is time well spent!

posted @ Friday, July 17, 2009 2:36 PM | Feedback (0)

Wednesday, June 17, 2009

Performing multiple Asynchronous Actions using TPL

I finally had a chance to install VS2010 Beta 1.Full instruction on how to here
VS2010 has undergone a major overhaul since VS 2008, a peek are some of the cool new eye candy can be found here
I've been waiting to get my hands on the TPL/PLINQ stuff and the Beta was definitely worth the wait. In a previous post we talked about using asynchronous actions for performing long running operations.

I was anxious to see how the new TPL stuff would help in achieving the same thing.

Interestingly enough, the TPL API is based on Actions as well, allowing both the generic and non-generic versions to be used for creating a Task(also supports Funcs).

The Thread pool has undergone some major rework, especially the scheduling algorithm is much more smarter now than the current implementation in.NET 3.5

The unit of abstraction is a Task as opposed to a Thread, so let's dive in and see how this looks and feels as opposed to the abstraction we previously built for asynchronous Actions. In the simplest form, the equivalent declaration for creating a Task that can execute an Action asynchronously looks like so:

public static void SomeMethod()
{
// do something here....
Console.WriteLine("In some method");
}
static void Main(string[] args)
{
var task = Task.Factory.StartNew(SomeMethod);
task.Wait();
}

You start a task and Wait for it to complete. Lets create a bunch of these tasks to execute on the GetUsers(), GetCountries() and GetLanguages() method from the previous post.

Task[] tasks = new Task[]
{
Task.Factory.StartNew(() => countries = GetCountries()),
Task.Factory.StartNew(() => countries = GetUsers()),
Task.Factory.StartNew(() => countries = GetLanguages())
};
Task.WaitAll(tasks);

This looks fairly similar from a usage persepctive to what we had for executing asynchronous actions

List<Action> actions = new List<Action>()
{
() => countries = GetCountries(),
() => users = GetUsers(),
() => languages = GetLanguages(),
};
actions.ExecAsync();

One obviously noticeable difference in using the Task is that you use the Factory method StartNew to create and execute the task at the point of declaration, and what you get back is a handle to the executing Task. So the Task[] contains a handle to all the executing tasks.
The ExecAsync extension method on the other hand is passed a collection of Actions to execute. I find the idea of being able to create and execute the Task in one statement very useful and terse.

Let's now compare the performance of executing Actions using Tasks v/s executing Actions using The ExecAsync()

public static class Extensions
{
public static void ExecAsync(this IEnumerable<Action> actions)
{
int count = 0;
AutoResetEvent[] events = new AutoResetEvent[actions.Count()];
IAsyncResult[] results = new IAsyncResult[actions.Count()];
for (int i = 0; i < events.Length; i++)
{
events[i] = new AutoResetEvent(false);
}
foreach (var action in actions)
{
int localCount = count;
results[count++] =
action.BeginInvoke((r) =>
{
try
{
if (r.IsCompleted)
{
Action act = r.AsyncState as Action;
act.EndInvoke(results[localCount]);
}
}
finally
{
//set the event regardless of whether there is an exception so that the main thread
//is not blocked indefinitely.
events[localCount].Set();
}
}, action);
}
WaitHandle.WaitAll(events);
}
}
public class Program
{
public static string[] GetUsers()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "Jack", "Jon", "Jim" };
}
public static string[] GetCountries()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "US", "UK", "Canada" };
}
public static string[] GetLanguages()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "English", "French", "German" };
}
static void Main(string[] args)
{
string[] countries;
string[] users;
string[] languages;
List<Action> actions = new List<Action>()
{
() => countries = GetCountries(),
() => users = GetUsers(),
() => languages = GetLanguages(),
};
Console.WriteLine("Running Actions Asynchronously");
Console.WriteLine("----------------------");
Stopwatch watch = Stopwatch.StartNew();
actions.ExecAsync();
watch.Stop();
Console.WriteLine("Total time taken:{0} milliseconds", watch.ElapsedMilliseconds);
Console.WriteLine();
Console.WriteLine("Running Actions using Tasks");
Console.WriteLine("----------------------");
watch.Reset();
watch.Start();
Task[] tasks = new Task[]
{
Task.Factory.StartNew(() => countries = GetCountries()),
Task.Factory.StartNew(() => countries = GetUsers()),
Task.Factory.StartNew(() => countries = GetLanguages())
};
Task.WaitAll(tasks);
watch.Stop();
Console.WriteLine("Total time taken:{0} milliseconds", watch.ElapsedMilliseconds);
}
}

Let's give it a spin and see the numbers:

The version using Tasks is almost 5 times faster! which suggests that TPL is doing a far superior job under the covers in effectively scheduling and executing the Actions.
TPL has a host of goodness which I've barely started exploring.Among other goodies, is the ability to have parent-child relationships between tasks and support for cancellation using a CancellationToken.
I hope to do more frequent posts especially around TPL since this has piqued my interest.
As always happy coding!

posted @ Wednesday, June 17, 2009 12:50 AM | Feedback (2)

Wednesday, May 13, 2009

Using multiple Object Contexts in a Transaction

The scenario: You have 2 Entity Models, and you need to call operations on the ObjectContext of each of them, the operations should be atomic, in that either both operations should succeed or fail so that your databases are consistent.
This is fairly straightforward to accomplish using a TransactionScope.
ObjectServices is smart enough to detect if the ObjectContext is in a surrounding TransactionScope and if so,use that scope.
NOTE:If a scope is not specified, then ObjectContext by default creates a new scope internally when saving changes.

using (TransactionScope scope = new TransactionScope())
{
using (RequestDBContext context = new RequestDBContext())
{
RequestType rt = new RequestType
{
Name="Test-2",
};
context.AddToRequestTypeSet(rt);
context.SaveChanges();
}
using (RequestDBContext context = new RequestDBContext())
{
Status stat = context.StatusSet.First(s => s.Name == "Pending Approval");
context.DeleteObject(stat);
context.SaveChanges();
}
scope.Complete();
}

In the above code I'm using the same EDM for both ObjectContexts, but I could very well use different EDMs.
If we reach the end of the 2nd using statement, then we can complete the transaction and persist all our changes.
If an exception is thrown then nothing is changed in the database and the transaction aborts.
Hope this helps.

UPDATE:5/16/09
Using TransactionScope requires MSDTC, the following links have good information to help setup/troubleshoot MSDTC for various environments
How to Enable MSDTC on a Web Server
New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2
Thursday, February 19, 2009 5:08 PM mmazur How to configure and troubleshoot MSDTC

posted @ Wednesday, May 13, 2009 11:58 PM | Feedback (0)

Sunday, April 26, 2009

Handling WorkflowRuntime events for IIS hosted WCF + WF services

The WorkflowRuntime class has a host of interesting methods and useful events. Events such as Completed, Perssited, Idled are invaluable when debugging and in understanding how a workflow instance is behaving.
These events are easily accessible when self hosting the runtime since you can just hook up event handlers for these events and react to these events as you see fit.
But, when the workflow runtime is hosted in IIS/WAS/Cassini host, you don’t have a direct handle to the runtime for hooking up these events.
The .svc file for the WCF service contains the WorkflowServiceHostFactory that WCF uses for servicing workflow service requests.

<%@ ServiceHost Language="C#"
Debug="true"
Service="RequestWFServiceLib.ApprovalWorkflow"
Factory="System.ServiceModel.Activation.WorkflowServiceHostFactory"%>

We can easily subclass WorkflowServiceHostFactory and replace the Factory attribute in the .svc file with a custom implementation of this class where in we override the CreateServiceHost Method and get a handle to the WorkflowRuntime and hook up the event handlers we need.

public class CustomWorkflowServiceHost : WorkflowServiceHostFactory
{
public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
{
ServiceHostBase hostBase = base.CreateServiceHost(constructorString, baseAddresses);
WorkflowRuntimeBehavior runtimeBehavior = hostBase.Description.Behaviors.Find<WorkflowRuntimeBehavior>();
WorkflowRuntime runtime = runtimeBehavior.WorkflowRuntime;
runtime.WorkflowIdled += runtime_WorkflowIdled;
runtime.Started += runtime_Started;
runtime.Stopped += runtime_Stopped;
runtime.WorkflowStarted += runtime_WorkflowStarted;
runtime.WorkflowSuspended += runtime_WorkflowSuspended;
runtime.WorkflowUnloaded += runtime_WorkflowUnloaded;
runtime.WorkflowCreated += runtime_WorkflowCreated;
runtime.WorkflowTerminated += runtime_WorkflowTerminated;
runtime.WorkflowResumed += runtime_WorkflowResumed;
runtime.WorkflowPersisted += runtime_WorkflowPersisted;
runtime.WorkflowLoaded += runtime_WorkflowLoaded;
runtime.WorkflowCompleted += runtime_WorkflowCompleted;
runtime.WorkflowAborted += runtime_WorkflowAborted;
return hostBase;
}
void runtime_WorkflowAborted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Aborted", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Completed", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowLoaded(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Loaded", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowPersisted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Persisted", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowResumed(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Resumed", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowTerminated(object sender, WorkflowTerminatedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Terminated", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowCreated(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Created", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowUnloaded(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Unloaded", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowSuspended(object sender, WorkflowSuspendedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Suspended", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowStarted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Started", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_Stopped(object sender, WorkflowRuntimeEventArgs e)
{
Debug.WriteLine("Workflow runtime Stopped");
}
void runtime_Started(object sender, WorkflowRuntimeEventArgs e)
{
Debug.WriteLine("Workflow runtime Started");
}
void runtime_WorkflowIdled(object sender, WorkflowEventArgs e)
{
Debug.WriteLine("Workflow runtime Idled");
}
}

the .svc file is updated to include the name of our custom implementation. That’s all there is to it.

<%@ ServiceHost Language="C#"
Debug="true"
Service="RequestWFServiceLib.ApprovalWorkflow"
Factory="RequestWFServiceLib.CustomWorkflowServiceHost"%>

posted @ Sunday, April 26, 2009 10:38 PM | Feedback (0)

Currently Reading