A couple weeks ago I popped up and wrote a little update on the reboot of the FubuMVC project. As of last week we’re running Dovetail on the new FubuMVC bits with zero references to the ASP.Net MVC framework. FubuMVC is very heavily convention based with the ability for teams to define and add their own project specific conventions a la Fluent NHibernate. I’m a big fan of Convention over Configuration, but it is magic. To make things manageable, we’ve added some nascent diagnostic abilities to FubuMVC to give development teams more insight into what’s happening inside the runtime objects and how those conventions get turned into runtime configuration.
The first step is to enable the diagnostics in your FubuMVC application. Much like StructureMap, all FubuMVC registration/configuration is done with one or more FubuRegistry objects. Inside a FubuRegistry, you can optionally turn on diagnostics with a call to “IncludeDiagnostics(bool)” where the boolean flag denotes whether or not to actually activate the diagnostics (you would not want this turned on in real production).
public class DovetailFubuRegistry : FubuRegistry
{
public DovetailFubuRegistry()
{
IncludeDiagnostics(true);
// and a bunch of other things
}
}
Turning on the diagnostics does two things:
- Adds 5-6 routes and their associated behaviors to your application to display configuration reports. Behind the scenes, these extra routes are added using FubuMVC’s mechanism for “Areas.” Fubu’s “area” or “slice” feature goes far beyond what MVC2 can do, so expect a blog post on this topic at some point.
- Replaces several services in the underlying IoC container with “recording” services to further trace requests and adds an optional mode that let’s you create a trace report for a URL instead of the normal output
Configuration Reports
Once you’ve enabled diagnostics in your application, navigate to the “_fubu” url directly underneath your application root and you’ll see this fancy web page with links to the real diagnostics.
The main report called “RoutesTable” generates an html table (totally unstyled at this juncture) that lists out every single Url configured in your application, when controller/service actions are invoked, and what the output of the behavior chain is (Json, web view, html, text, etc.).
Of course, running the web app just to get at this diagnostic information can be very painful and slow, so we have a purely textual output of the same information that you could generate inside of an NUnit test or a small console app for faster feedback cycles. My thought is that you would use this textual report to fine tune the conventions your team uses to generate routes, attach views and other outputs, and build up the behavior chain.
Request Tracing
Now, the part that I’ve worked on all day yesterday. In many cases you may be unsure what’s happening inside a single web request. What behaviors are being invoked, where is the model binding pulling information from, how long is it taking to run each step? With the diagnostics turned on, you can append a query string element to the end of *any* url like this: “my/url?FubuDebug=true” and FubuMVC will execute the request, but output a trace report showing:
- Each behavior that executed along with the amount of time spent inside that behavior
- Model binding events. What object was bound from the raw request and routing input, and where the model binding pulled the information (Route, Request, Headers, or Files).
- Exceptions
- Redirect requests
- Any Output is written to the request tracing as escaped text so you can examine the raw HTML or Json
More coming soon…
