Post 100! NHibernate Reporting Framework

Well, there may be a few things kicking around as draft only, but according to my main page here, this should be my 100th blog post.

Anyway, got started on some prototyping for the reporting stuff I want to do. There were a few initial head aches, but now I have something tangible. I really want to spend the time to model this appropriately and I think this is a very important piece of functionality, and I already have plans to re-use it in Veronica's software, but extensibility and reuse in general are things I'm looking forward to in this component.

So, the problem I wanted to solve; Reporting is a fickle mistress. People want reports on everything and anything. One day they may want to see a certain column and the next day they won't. One day they want a date range, next day they want a single date or maybe even all records. This sort of reporting is a bit of a pain. Using NHibernate only I'm forced to use my model objects to create custom data grids for every query. I could aim for a framework wrapped around those objects that allowed me to choose things like filters and columns to display, but I end up tied down to the original model objects. I may want to perform joins and the likes, and all I'm really concerned about is the data. Basically I wanted to just execute straight SQL and get a grid back similar to what one sees in Management Studio.

Now the fun part is that my shift to supporting Async methods means the client and server need to know everything about my objects in advance so passing generic types or attempting to build objects on the fly is out of the question. I needed a means of building a known object that can properly describe my search results. I've done this before, and working with NHibernate to get the data was relatively simple.

Step 2 in the prototype was a bit more fun. I needed to build a data grid, add the columns and bind them all in code. By the way, I have to thank Carleton University for not teaching me to design a UI using a graphical interface, every time I've needed to tweak an interface in code or write my own it has been so much simpler thanks to those days of writing my own GridBadLayout based UI's in Java. Getting the DataGrid and Columns was relatively simple. It was binding the data that turned out to be the hard part. Basically ended up building a custom converter, and then binding the converter and some parameters while building the Column and eventually got to a point where I can create a grid with an arbitrary number of columns based on any valid HQL query.

The next steps:
I'll need to come back to the drawing board and develop a proper plan for this component for it to be as much of a success as I want it to be, so this will be more a features wish list for the moment, but without further ado...
 - Support for aliasing in code (NHibernate doesn't seem to like column aliases, but can hack around this).
 - Support for specific data types (right now all variables are set in the query string, would rather take an array of objects and set them, more reliable this way)
 - Custom extension of the DataGrid class to reduce the amount of code in the screens using it.
 - Custom extension of the DataGrid Columns to support my supported data types.
 - Query Storage and Retrieval.
 - Make method which returns the QueryResult class take the ISession and do all of the work. This should allow for this code to be separated from the Repository and other code of the main application.
 - Create a standard WPF screen callable from the main screen which can display any query, expected to be default screen used.
 - Create a QueryReport object. Allow multiple queries and other data to be arranged into a common reporting template which can be used to show more than one query, static text, etc... basically a means of amalgamating related data.

But, I really haven't taken sufficient time to think about how I want this to look once I take it out of the prototype phase, so like I said, still a lot to do before this one takes off like I want it to. Might make use of some of the more obscure modeling and requirements features in Visual Studio for this one.

So, good for now.

Comments

Popular Posts