The back end in NH Prof is responsible for intercepting NHibernate's events, making sense of all the mess, applying best practices suggestions and forwarding to the front end for display.

Second, it is also a good example of how I apply the Open Close Principle at the architecture level. With NH Prof, there are multiple extension points that I can use to add new features.

Here is a schematic of how things works:

Not shown here is the NHibernate Listener (of which, of course, I have several), which is publishing events to the bus. Those events are first handled by the low level message handlers, which publish new events on the bus.

Those are interesting only in the sense that they translate the low level details into events with semantics that we can use in the app itself. Most of those events, as you probably guessed, end up in the Model Building part. This is responsible of taking a set of unstructured events into a coherent structure.

Along with the model building, we have another extension point here, best practices analysis. Those are implemented as a set of classes that we plug into the model building part. If we want to add a new best practice, we need to create a new class, register it, and we are done.

Here is the checkin for implementing the unbounded row set (which is ticket #51):

We add a new class (and a test for the class), register it in the BusFacility and in this case I actually had to fix a bug in the tested scenario, which loaded the wrong item.

I'll post more details about the actual implementation of Unbounded Result Set soon, but I wanted to talk about the architecture that enable this. Because we structured the whole thing around a common core that we can use, anything that fit the core (and most things does) doesn't require any special effort. Apply a new behavior, done.