Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

NH ProfBalancing functionality, simplicity and form

time to read 2 min | 215 words

There are two features that I want to get done before I call a feature freeze on NH Prof and just deal with any bugs and improvements that come up until I feel it is mature enough to call it v1.0.

One of them is filtering capability. This was a pretty common request once people started realizing the kind of things that they can do with NH Prof.

Ad hoc filtering into NHibernate’s activity can bring up a lot of insight, and I certainly think that this would be an good feature to have.

The problem is that while this is a good feature, it also introduce a significant amount of complexity. This wouldn’t be a problem if the complexity was on the application side. We can deal with complexity.

The problem is that I think that this introduce a not insignificant amount of complexity into the user's’ hands. Take a look at the mock UI that I created:


This isn’t the way it will end up looking, but it is a good place to start the conversation.

What is your opinion?

More posts in "NH Prof" series:

  1. (09 Dec 2010) Alert on bad ‘like’ query
  2. (10 Dec 2009) Filter static files
  3. (16 Nov 2009) Exporting Reports
  4. (08 Oct 2009) NHibernate Search Integration
  5. (19 Aug 2009) Multiple Session Factory Support
  6. (07 Aug 2009) Diffing Sessions
  7. (06 Aug 2009) Capturing DDL
  8. (05 Aug 2009) Detect Cross Thread Session Usage
  9. (22 May 2009) Detecting 2nd cache collection loads
  10. (15 May 2009) Error Detection
  11. (12 May 2009) Queries by Url
  12. (04 Feb 2009) View Query Results
  13. (18 Jan 2009) Superfluous <many-to-one> update
  14. (18 Jan 2009) URL tracking
  15. (10 Jan 2009) Detecting distributed transactions (System.Transactions)
  16. (06 Jan 2009) The Query Cache
  17. (05 Jan 2009) Query Duration
  18. (24 Dec 2008) Unbounded result sets
  19. (24 Dec 2008) Row Counts


Tobin Harris

For your design:


  • Relatively simple UI model to interact with

  • Requires few interactions to set up a filter

  • Simple to implement


  • Size of form will increase as more options become available.

  • Could be overwhelming to some users.

  • No live preview to see the effect changes have on your result data.

  • Not very funky :)

Another idea could be to have a filter builder, I've moqued up an example here:


This requires more work to implement.

My FAVOURITE filters are ones that you apply to the ACTUAL data as you're viewing it, where you can see results immediately, and tweak. So, you'd be able to click on the duration column in the results, and filter it directly. No need for a context switch.


Most backoffice views (be it desktop or html form) exists from three parts: search, overview and detail. It's a methodology we started using beginning 2001 for our online html based backoffice. Now we more and more are shifting towards WPF, IoC and Composite UI's (very roughly based on SmartClient Software Factory).

Let's say we want to query some customers. Our search screens don't perform the search itself, they only collect the input from the input element and assign them to a (disconnected) entity instance.

This instance is used to build the search query in what I find a rather simple matter:

('s' is a ISession and 'tx' is a ITransaction instance, 'cust' is the 'Customer' instance create by the search screen)

We start with a simple statement:

ICreteria q = s.CreateCreteria(typeof(Customer));

Than we start building up the where clause:

if (!string.IsNullOrEmpty(cust.Lastname))

if (QueryUtils.ContainsWildcards(cust.Lastname))

 q.Add(Expression.Like("Lastname", QueryUtils.PrepareSqlLikeString(cust.Lastname));


 q.Add(Expression.Eq("Lastname", cust.Lastname));

Other properties are added is a similair way.

All left to to is calling the List method to get the result:

IList <customer results = q.List <customer();


return results;

But than again, we always know what type of information we are looking for.

BTW: We use the normale DOS-like wildcards for backoffice users and replace the '*' and '?' characters with the correct sql versions ('%' and '_'). Because we check if a field contains wildcards we don't perform unneeded like queries.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats