I am currently working (well, sort of, more playing around) on the NHibernate Profiler. I thought that this would be a good time to describe how I approach most development tasks.

I don't actually have the time/strength to start serious development effort, but I have the time to do a lot of spikes, and to think about architecture. If I decide to spend the time making this happen, I'll post more about how it works.

I started with a spike about extracting the actual data from NHibernate. My target goal is being able to profile NHibernate 2.0 without having to modify NHibernate to support this. I actually run into some issues with that, more specifically, I run into technical issues with my chosen approach. Instead of spending time on troubling shooting that, I chose another path. That may not be the way it will end, but I am not interested in the technicalities at the moment, I am interested in the feasibility of the project. Suffice to say that I was successful (and learned a bit about named pipes :-) ).

Next, SQL formatting is a pain, but it is something that is mandatory for a profiler, a least if you want to let the users a fighting chance in understanding what is going on. I found a solution for that as well, which I am extremely pleased with.

Next is not the actual application architecture, but the user interface. That helps nailing down what the application is going to do, and cement what it is going to do. I am also a great believer of building from the top down, and the architecture that I have in mind make it very simple to split back end processing from the front end.

This is an example of what I have in mind. This is concept UI. It is not meant to be the final thing, it is here merely to give me an idea about what I am going to build. This UI was generated with the assistance of power point and paint, the disclaimer is what I usually put whenever I create a UI.

What you can't see, and the purpose of the UI building exercise, is the mental model that it helped me create (the main concepts in the application are sessions, statements and warnings/suggestions). There is a streaming rule set that process those, and a whole set of functionality that just sits there in my head.

The next step, at this point, is getting from a UI sketch to a working UI draft. What do I mean by that? It means building the UI (which will intentionally look ugly) and hooking it to a dummy back end. The reasoning here is quite simple. I don't care for the look and feel at the moment, that is utterly uninteresting to me at this point, because I have seen what real UI developers can do, and I am not in their league so I am not going to even try.

What I do care about in this stage is the actual operation of the UI. I can hand it over for the professionals to handle the beautification process after that part work. Of course, I feel bad about not knowing more about this, so I may spend more time there than I should, but I am going to try.

After the presentation layer is done, we can start focusing on the actual back end. That is going to composed of event processing pipeline with a set of rules that I can use to provide warnings and suggestions about what to do. Still debating the interaction between the back end and the front end. Most likely this is going to be a simple ThreadSafeQueue<T> and that's it.

Oh, and here is the total sum of code written so far:

And if you think that this is interesting that I am not showing code, you are right, what is see is what is :-)