Objects Can Beat Recordsets for Display

In the old days (for me, about six months ago!) we all wrote queries and used cfoutput to display the results. These days we often use beans loaded by a DAO for single records instead. Why? They are a little more trouble, but even for data you only plan to display, encapsulating the getters allows you to vary your implementation (how a particular attribute is calculated or what internal properties it depends upon) without breaking your interface (you still just call the getter) . . .

In many cases this really doesn’t matter, so for many applications there is a story to using a recordset for all display data (single record or collection). It is easy, it performs well, and it avoids unnecessary complexity.

However, if you have an application where you want to use a bean for single record display purposes, why wouldn’t you just use a collection of beans for displaying a collection of records? What, it is important to encapsulate one record, but if you’ve got a bunch of them you’re just going to let it all hang out?!!! It makes no sense (actually, it could make sense if the only fields you needed to encapsulate are ones that are never shown on your master/list pages, but to me that is a heck of a fragile way of building an application!).

So, let’s take my prototypical use case for getters. I have a user table with FirstName, LastName and DateofBirth properties, but I want to be able to display FullName, FirstName, LastName, Age and/or DateofBirth. Also, any of those fields may be used in an individual record or in a master/list view. This may be too simple a case to be worthy of the discussion, but I hope it is a good real world example of the type of problem we are looking at.

So, I want to display Age on a view. No problem, I get my bean and call User.getAge() to display the age. Inside the bean there is probably a custom getter operating on the DateofBirth field, who knows . . . who cares?! But now I want to display Age in on a list page. What to do?

One solution would be to duplicate the code – hopefully in the model (what should a display page know about calculating ages?!), but I really don’t want to repeat myself unless I have to (lets stay DRY). I could push back the creation of Age and FullName to the database, but I don’t really want my business rules in the database and there are some calculations that can’t easily be performed in SQL (especially if you have to worry about cross db considerations).

What I’m suggesting is that we already have the code – right there in the bean. Many java developers would just create a collection of beans, iterate through them and be done with it, but component instantiation is expensive in CF, so it would be nice to have a higher performance way of obtaining the same results.

Luckily there is one. Just load the query into a bean, add the ability for the bean to iterate through the query (such as with first(), next() and IsLast() methods) and return that bean to all of your display code. Whether you have 1 record or 0..n records you pass the same object and can use the same code (getters and/or setters). Stick all of this into a baseBean that all of your beans inherit and it is extremely easy to work with. I’ll post sample code early next week.

This also means that if you have a lot of dynamic display code that can be used to display 1 or 0..n records, you don’t have to have two versions (one with #FirstName# and the other with #myUser.getFirstName()#). This will probably make more sense as I get a chance to blog about how I’m doing displays and a bunch of other things, but for now:

If you need getters for your object views (if you are displaying calculated attributes or just want to encapsulate accessing of your data)
AND
If you want to display calculated attributes on both list and view pages
THEN
Consider using a bean with a built in iterator to get the benefits of encapsulating data access without the performance costs of instantiating a collection of objects or the maintenance costs of duplicated code.

As with all approaches, your mileage will vary. This is not the "one true way" to handle data you primarily want to display – both in views and lists. It is an approach to consider.