NHibernate web console

When developing web apps, I sometimes need to poke into the app's database, or try out some query. When it's a SQL Server database, I have Management Studio. But what if it's SQLite? Or Firebird? Even when it's SQL Server, most of my apps use NHibernate and I'm really spoiled by HQL. And if it's a local embedded database, you have to browse and open the db file. Boring. I already have the app URL, that should be enough.

So I built a NHibernate web console. It's kind of like NHibernate Query Analyzer, but more web-oriented. Here's a screencast showing its features:

A couple of features that are not evident from the screencast:

• Bookmarkable: I wanted to able to copy the URL with a query and send it to a teammate: "See, this isn't right". Of course, updates/deletes/inserts are POSTed, not GETted, so no bookmarks.
• Easily embeddable: A single DLL with no external dependencies (except .Net 3.5 and NHibernate itself, of course)
• Easily configurable: you only need to tell the library how to get to the NHibernate Configuration and ISession (or ISessionFactory) at application start, and add the HttpHandler to your web.config.
• Accesskeys: ALT-Q goes to the query editor, ALT-X executes the query, ALT-, goes to the previous page, ALT-. to the next page. (Firefox uses SHIFT-ALT instead of just ALT)

Yeah, I know it's butt-ugly and a little rough around the edges, but still it's pretty usable (at least for me).

DISCLAIMER / WARNING: it's up to you to secure this if you put it in a production website! Also, there is no query cancellation, so if you issue a 1M-results query you will effectively kill your app!

Code is here.

UPDATE: just added RSS support for query results.

Windsor-managed HttpModules

Another interesting question from stackoverflow:

I have a custom HTTP Module. I would like to inject the logger using my IoC framework, so I can log errors in the module. However, of course I don't get a constructor, so can't inject it into that. What's the best way to go about this?

First thing we need to recognize is that there are actually two problems here:

1. Taking control of IHttpModule instantiation in order to inject it services, and
2. Managing the lifecycle of the IHttpModule

Let's start with the lifecycle. Ayende has the best summary of the lifecycle of HttpApplication and its related IHttpModules I've found. If you're not familiar with this, go read it now, I'll wait.

Back so soon? Ok, we can implement this in Windsor with a pluggable lifestyle. Lifestyle managers dictate when it's necessary to create a new instance of the component, but not how. They don't get to actually create the instance, that's the responsibility of the component activator. Here's the full component creation flow reference.

So we need to write a new lifestyle manager that allows at most one component instance per HttpApplication instance. I won't bother you with the implementation details since it's very similar to the per-request lifestyle: it's composed of the LifestyleManager itself and a HttpModule as a helper to store component instances.

Now we need a way to manage the IHttpModule instantiation. Unsurprisingly, we can do that with another IHttpModule, which I'll call WindsorHttpModule.
This WindsorHttpModule will be responsible for the initialization of the "user-level", Windsor-managed IHttpModules.

So, to summarize:

1. Register PerHttpApplicationLifestyleModule and WindsorHttpModule:
   

   <httpModules>
       <add name="PerHttpApplicationLifestyleModule" type="HttpModuleInjection.PerHttpApplicationLifestyleModule, HttpModuleInjection"/>
       <add name="WindsorModule" type="HttpModuleInjection.WindsorHttpModule, HttpModuleInjection"/>
   </httpModules>

2. Write your http modules using normal dependency injection style, e.g.:
   

   public class Service {
       public DateTime Now {
           get { return DateTime.Now; }
       }
   }
   
   public class UserHttpModule : IHttpModule {
       private readonly Service s;
   
       public UserHttpModule(Service s) {
           this.s = s;
       }
   
       public void Init(HttpApplication context) {
           context.BeginRequest += context_BeginRequest;
       }
   
       private void context_BeginRequest(object sender, EventArgs e) {
           var app = (HttpApplication) sender;
           app.Response.Write(s.Now);
       }
   
       public void Dispose() {}
   }

3. Make your HttpApplication implement IContainerAccessor
4. Register your http modules in Windsor, using the custom lifestyle:
   

   container.AddComponent<Service>();
   container.Register(Component.For<IHttpModule>()
                          .ImplementedBy<UserHttpModule>()
                          .LifeStyle.Custom<PerHttpApplicationLifestyleManager>());

   
   Note that UserHttpModule is not registered in the <httpModules> section of web.config, since it's managed by Windsor now.

You can also combine this with Rashid's BaseHttpModule to make your modules more testable.

Full source code is here.

Powered by SolrNet

Some websites and products that use SolrNet:

• http://www.fancydressoutfitters.co.uk by EMC Consulting
  The core architecture is based on the S#arp Architecture framework (with added support for multiple databases, ViewModels etc...) 
  Integrated other OSS projects into the solution:
  • N2CMS
  • Spark View Engine
  • xVal Validation Framework
  • AutoMapper (for entity / view model mapping)
  • PostSharp (for cross cutting concerns - logging, performance counters, caching)
  • MBUnit / Gallio for our BDD Framework
  • Over 700 BDD Specs
  • Solution performs very well - 1000 concurrent users per web server, generating around 180 pages per second across 2x single quad core 64bit servers.
• http://jobhits.co.uk by Duc Lai
• http://www.leasetransfer.com by me (not my web design)
• http://www.bedriftsoket.no by Steinar Asbjørnsen
• EPiSolr by LBi

I'll keep an updated list on the project's wiki. If you have a public website using SolrNet, let me know!