When talking about Glimpse and extensions, a lot of attention goes towards the package ecosystem. This contains plugins which provide insights into the various frameworks you use. This makes it very easy to get up and running, and gain deep insights into your application and the systems it’s build on. The barrier to entry is very low and the reward is high, but you still aren’t getting the most out of Glimpse.
With very little effort, it’s possible to have this same instrumentation for the custom code in YOUR application. Image if your application could tell you its current state and give you a picture of logic its executed. What if people working on your project had a full diagnostics console which showed how the custom parts of your application is operating.
This would make dealing with parts of the system you hadn’t built much easier, and provide a much better onramp to those coming to your project for the first time. This woul bring the same level of understanding that you have come to expect from the standard Glimpse packages, right to the custom parts of your application.
For me some examples of what might be possible here are as follows:
- Show the current state of a custom configuration object in your system
- Show the content of a shopping cart style of component you might have written
- Current state of a work flow that you have progressed through
- Security checks that were conducted to build the page (what passed/failed)
This post is the first in a series of posts looking at your code and your plugins. We will be looking at how Glimpse can be leveraged to show specific details for your system. To start with, we are going to take the first example listed above and see what code it would take to make it work.
Use Case 1: Show the current state of a custom configuration object in your system
In this example, we have a database table called
Configuration. The idea is that we want to store information like tax rates and markups in the database so we can update them easily. For this case, we are going to put aside that you could do this via the web.config and focus on the idea.
Here is the code that makes up the static Configuration hook mentioned above:
Under normal circumstances, we would have very little idea about the state of these object. We could go to the database and query the table directly, but at that point we are assuming that this is the same as what the application has in memory.
In this case, because we aren’t happy with making this assumption and we want to know what we actually have in memory – the thought being:
- Incase some exception caused only a partial load, or
- we have some impedance mismatch between the database and the class, or
- we have some sort of post processor which interprets/modifies the data before populating the object
With our current set of tools, we could set break points in our code so we can manually inspect the object or dump the object out to a log file. Unfortunately, these solutions are time consuming, cumbersome and less than ideal.
Having heard about Glimpse and used it in other projects, you decide to see if it has anything to offer. You find out that you can easily create Tabs to show arbitrary data. You decide that you would like to see a Tab which shows the state of your Configuration object.
Creating Tabs within Glimpse is incredibly easy. Once Glimpse has been added to your project, the runtime will detect any class in your solution that inherits from
ITab. This process means that there is no configuration xml or registering of classes to get up and running.
This is the only code you would need to give Glimpse the data that you would like to populate your Tab:
For the sake of completeness, here is a trivial example of how you might manually go about populating the Configuration object in the first place (note, this is just one of many):
If you are interested, here is the link (4639363cff) to the MVC Music Store sample which has the commit for the above functionality. Feel free to play around with it and modify.