Monthly Archives: October 2012

The Problem

I’ve been struggling for awhile to figure out how to get Entity Framework to set and unset application roles in Sql Server when opening and before closing a connection. The problem is that ConnectionState does not provide a Closing state that fires before a connection is closed.

It was suggested to me to turn of connection pooling. Errrr, no. We want connection pooling for our applications. I also don’t want to have to manually open and close the connection every time I create a DbContext. That’s just messy and irritating.

The next obvious thing to do would be to create a DbConnectionDecorator to wrap the existing database connection and expose the Closing event. This proved to be very difficult because Entity Framework does not expose when and how it opens connections.


The Solution

What’s that you say? I can implement my own EntityFramework Provider? There’s a provider wrapper toolkit I can plug into to do this? Awesome!

Oh wait—that looks really, really, REALLY complicated? You mean I can’t just decorate a single object? I have to decorate a whole family of objects?


Alright, tell you what I’ll do. I’ll implement the provider wrapper using the toolkit as best I can—but then I’m going to strip away everything I don’t actually need. Besides, if I just make the various data related events observable, it’s nothing to Trace the output. And Cacheing can easily be added as a IDbContext Decorator anyway. I don’t really get why that should be done at the Provider level.

Configuring Your Application to use the Provider

To use the new provider, first install the package. At application startup, you’ll need to register the provider and tell it which other provider you are wrapping. The registration process will set the ObservableConnectionFactory as the default connection factory used by EF unless you pass the optional setAsDefault:false.

Consuming the Provider Events

ObservableConnection exposes several new events, including Opening, Opened, Failed, Closing, and Closed. However, to subscribe to those events directly requires that you cast the DbConnection exposed by EF to ObservableDbConnection, which strikes me as a little cumbersome (not to mention a violation of the LSP). My first use case demands that I handle the Opening and Closing events the same way for every DbConnection application-wide. To that end, ObservableDbConnection (and ObservableDbCommand) pushes its event messages onto a static class called Hub.


This code is brand-spanking new and it hasn’t had time to bake yet. I’m using it, but it’s entirely possible that there are unforeseen problems. Feel free to report issues to and/or contribute to the open-source project on BitBucket. Until then, know that it has been rigorously test and that it works on my machine.

works on my machine, starburst

Review: HTML5 Conference in Austin, TX

I didn’t realize this when I signed up, but the DevCon5 Html5 Summit was a conference within a conference. The larger conference was an ITEXPO. The ITEXPO conference was focused more on infrastructure than development—in fact as far as I could tell, HTML5 was the only developer-centric conference at the entire event. This did not turn out to be a good thing for me. I noticed maybe 20 or 25 developers for the HTMl5 portion of the event.

The Negative

The sessions themselves had a few problems. First, the focus was almost all on mobile and app development. I realize that the world is changing and that more and more people are developing for the mobile platforms, but there are an awful lot of us that are building applications for the business we are trying to support. It would be nice if someone would discuss benefits to the business of the new HTML5 goodies. There was a little of that in the sessions, but it wasn’t very meaty. Yes, it’s great that you can make images float across the page, but my business users don’t really care about that.

The second problem, which perhaps isn’t the speaker’s fault, is that no one was really super-excited about HTML5. Since the focus was on apps for the mobile platforms, most speakers spent time acknowledging that the write-one-run-anywhere promise of HTML5 isn’t a reality, and likely wont’ be for a long time (but it’s getting better!).

Another issue with some of the speakers is that they did not seem to know very much about HTML5. If I had to reverse-engineer their talk, I would say that there was something they wanted to learn about, they learned just enough about it to fill up an hour of speaking, and then stopped. They were unable to answer questions about possible uses for the bits they were covering beyond their demo. Several speakers also did not have working demos.

The Positive

The best part of the sessions is that I got a lot of tools and references to other sessions that might fill out some of what’s missing. Here are some of the things that were referenced:

There were a very few principles and practices discussed. They are:

  • Get familiar with messaging in javascript.
  • If you’re going to support mobile, develop for mobile first—then the desktop.
  • 1 class per js file.
    • I especially like this one because it implies that you should still be writing classes in javascript.

Presenters I’d Like to See Again

Instead of picking on the presenters I thought were less than spectacular, I thought it would be better to shout the names of those who were particularly good. These are people that I’d enjoy talking to about web development again.

  • Jonathon Morgan – His talk on HTML5 vs. Native apps was well-reasoned and balanced. His enthusiasm for development was refreshing.
  • Tom Shafron – He is the current CEO of Viewbiquity. His session was on machine-to-machine communication in javascript. It was in his talk that we got into javascript best practices and patterns.
  • Jesse Cravens – His session on node.js was substantive and interesting. Most of the libraries mentioned above came from his presentation.