January 2006


There are two ways of selecting a list of objects in NHibernate based on a set of criteria.

One is using the IQuery interface which let you build a query using a sql like syntax. The other is using the ICriteria interface, which is a more object oriented way of creating a query.

I like the ICriteria way much more, but I found out that IQuery is much better in terms of performance.

I am working on a small project for a client that wants a website for engine tuning enthusiasts. I found out that the some of the pages that included searches were loading quite slowly, so I decided to try to optimize the performance.

I was using ICriteria and as an example I will show you how I filtered by a specific brand and ordered the result:

ICriteria crit = session.CreateCriteria(typeof(Car));
SimpleExpression exp1 = Expression.Eq(“Brand”, brand);
crit.Add(exp1);
Order order = Order.Desc(“HorsePower”);
crit.AddOrder(order);
IList carList = crit.List();

With the Expression-class you can create different comparisons, Gt/Like/Lt etc. and the order can of course also be ascending. I think it’s an elegant way of creating a query.

But then I tried to use IQuery instead, which in this example would be:

string q = String.Format(“from Car where BrandId = {0} order by {1} desc”, brand.Id, “HorsePower”);
IQuery query = session.CreateQuery(q);
IList carList = query.List();

This is much more SQL-like and to be honest I don’t want to be preoccupied with placing where’s and order by’s in a string, especially when there are many parameters and not all of them always are set.

But well it turns out that the search was 4-5 times quicker using IQuery.

It says in the description for ICriteria that it’s still an experimental API, so that’s probably why, but I’m a bit unhappy it’s performing that bad.

Although I primarily develop on the .Net-platform, occasionally I do other projects like php based web applications. One of those, was a web application to manage real estate, i.e. publish properties for sale and facilitate contact between buyers and sellers. The application had to be based on a Content Management System for the client to be able to keep maintaining the site afterwards.

So we found the Hot Property component from mosets, which is a “plugin” to the opensource Mambo/Joomla CMS made in PHP/MySql. I didn’t have experience with Joomla, but since there are a lot of users by now and it looked pretty profesional, I didn’t have any problems taking on the job, and it would give me some valuable experience as well.

At first everything looked good. The installation went fine, I had to reinstall once though, because of a SAFEMODE = ON setting that the webhosting won’t change, but in general it went pretty smooth and it was easy to diagnose the problems that rose on the way and find a solution.

But then came the actual management of the CMS. I must say, I’m really really surprised that a CMS with a 5 year history, which has won several prices can be lacking so much in terms of usability and information architecture. I have worked with other CMS’es before (like DotNetNuke) and I’ve never taken so much time getting into the system and doing the things I wanted to do.

My experience is based on 5 hours of trying to set up the basics of the site, so I obviously didn’t get an understanding of everything, nor can claim this to be an exhaustive evaluation. But one thing that jumped into my eyes is that nowhere in the admin menu is there any term called a “Page”. All websites consists of pages, so it’s just such a basic notion that I don’t understand why the CMS is not built around that. There are probably good reasons for dividing everything into Sections, Categories, Content Items, Modules and Components, but it makes it really hard to know where to go, to do the things you need to do. I’m sure these abstractions have been thought over and are valid from some point of view, but I remember what I learned back in university, that one of the points of Object Oriented Development is to base the domain model on the real world, i.e. actually using the terms that people in the domain area use.

Another example was the simple issue of having a static text on the front page saying “Welcome”. This was almost impossible to do. Read an excerpt of a response I got from another developer:

“I think you will find the answers will lead you to one of the following:
1) Hardcoding the welcome message into the page template.
2) Making a static content link in your main menu, then making that link the first link in the main menu, since that’s how Joomla determines what the ‘homepage’ is.
3) Create a new module and place the greeting in there. Assign the article to an unused module position (ex. user8). Then in the template index file assign the module right above the MainBody. (Then possibly use code and/or the module parameters to only get the module to appear on the front page).
4) Probably a temporary solution, though the one I’m actually using (because it’s a small site and I’m the only one who adds content), I just created the welcome as a regular news article, and keep moving it to the #1 position manually.”

It just looks like it wasn’t thought of, when the system was developed. I always advocate taking the users point of view, and trying to build the system seen from his/her eyes, hopefully in collaboration with him/her. This might sound obvious, but in many cases isn’t, and I can sure say that either I represent a target user that the system was not built for, or they simply never did a basic usability study and test.

There were other issues as well, and my conclusion was, that if I, an experienced IT person, can’t use the CMS pretty intuitively, there is no way that my client, who is less experienced, will be happy with it. I’m not happy with that, and would definitely want to hear from users with positive experiences or perhaps suggestions for other CMS’es to choose instead.