I can see why you might have thought this to be true, since the code _does_ have a PayrollDatabase object; and one simplistic implementation of that object might be to bind it directly to a SQL database.  Indeed, early in the development of the application, such an implementation would likely be the norm.  On the other hand, what if I were using an in-memory database? What if, prior to executing this code, I simply cached all the employees in memory?  What if I were using CouchDB, or Mongo, or BigTable?  Or what if the PayrollDatabase object was clever enough to fetch and cache 50, or 100, or 1000 employees every time it got a cache miss?  Would you have the same complaint?

The point is that there are many interesting ways to avoid coupling your business rule code to the hard details of a relational database.  And there are many reasons why this is a good idea.

Databases are details; they are not the core of your system.  A good system architect pushes the database out to the edges of the system and breaks all couplings of the use cases and business rules upon it.  This allows the system to use any kind of data storage mechanism it might need, now, or in the future.  

Davy, you are absolutely right.  If I knew that I was using a SQL database, and would always be using a SQL database, then I would change that algorithm to take advantage of that knowledge.  But I don’t know that I’m using a SQL database.  I don’t know it because I don’t _want_ to know it.  I want that information hidden, because I don’t want to depend upon it.  That means that I am free to write the business rule code in the manner that seems most expressive and clear to me; and to move the problem to the code that connects the business rules to the database.
For more on this, see the cleancoders.com videos on Architecture, Form, Functions, The Single Responsibility Principle, and The Open Closed Principle.  

criticizing code in a blog post and working with teammates are two entirely different things. for starters, when one of my teammates writes code that needs improvements, i explain them what’s wrong with it and how we can improve it. There’s no criticizing going on there.

Peter.

Basically, you are assuming a particular implementation of the PayrollDatabase, and are criticizing that implementation. I have worked on many projects where the ORM is smart enough to optimize cases like this, or where the data is already in memory, and I only “pay” for the method call. (The only thing I would change is to remove the part where we get the IDs, and instead get an iterator over the objects. If you want to criticize an API that exposes arbitrary IDs, I am fine with that.)

If paging really is necessary, a good solution to this problem is something that’s probably gonna require a bit of experimentation… i can’t just think of something that would definitely be great for this situation… sorry

Therefore, what solution would you use in this particular case ?

I’m trying to create a ‘PagedResults’ class, which is given an ICriteria.
The PagedResults class would then use the SetFirstResults & SetMaxResults methods to retrieve the required entities in ‘chunks’. But, then I am faced with the problems I’ve described in my earlier comment.
So, I’ve decided to modify my ‘PagedResults’ class a bit, so that I first retrieve the next ‘n’ Id’s, and then I let NHIbernate retrieve the entities for those Id’s (in one go), but this is a bit problematic as well …

Suppose you’ve an entity that is mapped against multiple tables. In other words, the entity has a number of collections which contain related information.
For instance, you have a class ‘Product’, which has a collection of ‘Prices’, and a collection of ‘Names’ (for every language, a different name), etc…

You need to write the Product information to a file, and this file contains, for each product, the price that is currently valid, and the ProductName for a specific language.
(You cannot use a DTO to retrieve the Products ).

If you use the ‘paging’ capabilities of NHibernate, NHibernate will issue several SELECT statements, which retrieve a recordset of n rows (where n is the ‘page-size’ that you’ve specified).
However, this recordset of n rows maybe contains information for n / 2 entities:
Since the entity has a collection of Names and Prices, the recordset contains a row for every Product/ProductName/ProductPrice.
This means that, if a product has 2 names and 3 prices, the recordset will contain 2*3 records for one Product.
Then, the pages will contain fewer entities then you’ve specified.

How would you solve this ?
One could argue that the Names and Prices should be loaded lazily, but, when you do that, you’ll find yourself in the same situation as the piece of code you’ve posted:
multiple queries will be fired in the loop where you iterate over every Product that you’ve loaded …

and again, as far as the readability is concerned, i’ll just copy/paste something from one of the earlier comments:

“how is the above code cleaner, simpler and more readable than simply looping through the return value of PayrollDatabase.GetAllEmployees?”

Using an ORM-like approach is a good thing, code is read much more times that it get’s writed, and if the performance of the program is Ok I don’t see a reason why “optimize” it. The question here is: Is it worth to optimize the code to make just one SQL query instead of six?

Premature optimization is the most common cause of project failures.

If we’re only interested in the employees whose pay date is today, why pull all the employees out of the DB? A simple where clause would return only the employees of interest, shifting computation to the most optimised place (the DB server) and generating a much smaller set to loop over.