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.
Grrrrrr.
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?
Hmmmm.
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.
Guarantees
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.
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:
- Videos of talks by Jake Archibald (These are very good, though… “colorful”)
- PhoneGap: a library that intends to do for mobile devices what jQuery did for browsers.
- bootstrap: Get a nice-looking site styled after twitter fast
- enhance.js: a progressive enhancement library
- modernizer.js: a progressive enhancement library
- create.js: an in-place content editing plug-in
- jqtouch: a jQuery gestures plugin for mobile web development
- Reactor Pattern
- A SPDY alternative to HTTP
- node.js: server-side javascript environment
- Cloud 9: A web-based IDE for working with node.js
- Canvas Pad: a live test environment for learning to use the HTML5 canvas
- Socket.IO: a façade library for web sockets
- yeoman: a suite of tools for building web sites
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.
