The tracing and caching providers (or here) provide an excellent way to trace and cache EF queries. Unlike those that attempt to do the same above the EF API, these providers work under the covers and make tracing and caching non-invasive for the application code. Specifically, for cases where entities are lazy-loaded via EF and those entities are to be cached, this caching provider is truly more advantageous.

However, these providers were written before EF 4.1 code first and they wouldn't work if you just follow the old sample. Luckily, it is not too difficult to make them work. The trick is to create a wrapping EFCachingConnection or EFTracingConnection that wraps a DbConnection (such as SqlConnection) and pass it to the DbContext constructor. I will just demonstrate the caching related code here but you should be able to chain tracing, caching and then the underlying SqlConnection using the same pattern.

First, a minor modification to the EFCachingConnection constructor is needed. As shown in the following code, we need to be able to set the wrappedProviderInvariantName via the ctor:

26.  


27. public EFCachingConnection(DbConnection wrappedConnection, string wrappedProviderInvariantName)


28. {


29. this.WrappedConnection = wrappedConnection;


30. this.CachingPolicy = EFCachingProviderConfiguration.DefaultCachingPolicy;


31. this.Cache = EFCachingProviderConfiguration.DefaultCache;


32. base.wrappedProviderInvariantName = wrappedProviderInvariantName; // make it possible to set the wrappedProviderInvariantName via this ctor


33. }

The I use the following helper function to create an instance of the EFCachingConnection that wraps a SqlConnection:

56.  


57. public static EFCachingConnection CreateEFCachingConnectionWrapper(string nameOrConnectionString)


58. {


59. string connectionString;


60. if (nameOrConnectionString.Contains("="))


61. connectionString = nameOrConnectionString;


62. else


63. connectionString = ConfigurationManager.ConnectionStrings[nameOrConnectionString].ConnectionString;




65. DbConnection connection = new SqlConnection(connectionString);


66.  


67. return new EFCachingConnection(connection, "System.Data.SqlClient");


68. }

Now you would simply pass the newly constucted EFCachingConnection instance to the ctor of DbContext:

100.  


101. public MyContext(DbConnection connection)


102. : base(connection, true)


103. {

Note that MyContext is the application's EF code first context, which derives from DbContext and has probably overriden the OnModelCreating() method.

Last and not the least you would need to call EFCachingProviderConfiguration.RegisterProvider() first when you start your application.

Happy holidays and happy EF coding!

We are building a web application that integrates with a third party software by embedding their Flex objects in our ASPX pages. When we started using VS.NET 2010 Web Performance Test, everything worked fine except for the weborb requests made by the Flex objects to the server. Basically, the requests recorded by the web test, when played back and sent to the server, were causing the server to respond with errors. From googling, it looks like that the same issue has been experienced by other folks as well. At this point, it would be easy to simply dismiss VS.NET 2010 Web Performance Test as a viable tool for Flex. What a costly mistake this would have been if we had stopped doing more analysis!

Looking at the initially recorded tests, I found out that all the data posted by the Flex objects was recorded and played back as string data type. Examining the payload in Fiddler, however, showed that the data is obviously binary. So our recorded test was sending the data with lost fidelity and the server just choked.

Thinking that there must be configuration to tweak to make our tests record binary data, I started searching MSDN for documentation. Sure enough, I found this link. I went ahead and added "application/x-amf" as the content type. Then I recorded the test again and ran the scripts.

Voila, everything worked like a charm!