I recently started working on a new DAL during my day job. We’re using PetaPoco for the most part, and we have it separated out into it’s own assembly. One reason we did this was because we foresee needing this in multiple projects, possibly even creating a service. After I got a test case working in the web application that was consuming the DAL, I wanted to see if I could get PetaPoco to work with Glimpse. Sure enough, there is a PetaPoco.Glimpse project in the NuGet repository.
I quickly installed the package in my web assembly and ran the project. As I opened up Glimpse and clicked on the PetaPoco tab, I was greeted by a message telling me that no appropriate database had been used. I started looking at the code (probably should have done that before I ran the project) and realized that the way the profiler worked for PetaPoco was to use a new database object DatabaseWithProfiling. I did some searching and came across the author’s blog. Here he details that the best practice is to create a new database type that derives from the DatabaseWithProfiling.
As I looked at this, it wasn’t an option for us. Our database class existed in a separate assembly. The DatabaseWithProfiling had a dependency on HttpContext in order to determine the database timing for each request. Since this separate assembly was not a web project, it did not have HttpContext, and it seemed wrong to include it just for profiling.
Likewise, it seemed wrong to move the DAL code out of this separate assembly into the application, since we knew of at least one more application that would need access to the same database.
A third option came up, and that was to create an IDatabase which is basically an interface representation of the PetaPoco.Database object. The advantage here would be that we could have the IDatabase exist in our DAL assembly, while having the concrete class exist in the application. As we discussed that option, there were reasons that we didn’t like it either, one of them being the main reason to implement that would be to enable profiling.
We discussed a couple other options before we finally settled on one. We created a database class derived from Database, and added a dependency to a new IProfiler interface.
Then in the consuming application, the concrete class takes the information sent via the Update method, and adds it to the HttpContext list.
And here’s the class that holds the profiling information:
The PetaPocoGlimpse template was also slightly modified so that it used the new DataProfiler class, and not the DatabaseWithProfiling.
I’m posting the code here and not as a NuGet package for a couple reasons. First, I don’t want to call it PetaPoco.Glimpse2 or something as equally ridiculous (because I’m not affiliated with either project.) However, if I name it something completely different, it will be hard to search for.
Secondly, the main change is the addition of an interface, and modifying an existing PetaPoco.Database class. It does not create a new one.