Sometimes, a query should just be a query

I don't think this is quite as bad in 2008 as it was a couple of years ago, but there has been a propensity for CF developers who are trying to use MVC and create OO CF applications to lose sight of the KISS method of development - Keep it Simple, Stupid!

ColdFusion's beauty is in its simplicity, but there are many CF developers that seem to have a love/hate relationship with this simplicity. It's either they intentionally add a lot more complexity to their applications, or that they actually wish it were harder! We see CF developers that seem to trash ColdFusion every chance they get, and I can't understand why for the life of me.

I used to be a procedural developer, but I am definitely an OO developer and have been for a while now. I use Mach-ii and ColdSpring every day, and am pretty darn good at it! So, I don't want to sound like I am bashing OO. I am just saying that there is good, responsible OO, and then there's pseudo-OO, where there are getters and setters everywhere that really do nothing. Your objects need to DO something, and not just exist because they look like OO.

OO is great, but there's a time and a place for it. To be clear, I am talking pragmatism and using what the language is best at over theory. Not everything should have getters and setters and return an array of objects. I've known for some time now, anecdotally, that, most times, a query should just stay a query. There are no reasons to convert them into objects if they can be represented as a query. Unless they represent a single object that needs to be manipulated, you don't need them. Often, if you need a more complex structure, returning an array of structures, versus an array of objects, will give you MUCH better performance.

There is best practice, and maintaining good applications with no more code than you need. But, in Rob's blog, there's also legitimate technical reasons why you should use no more objects than you have to. Rob has a series of posts called "Object instantiation and heap size in ColdFusion".

Part I
Part II
Part III
Part IV

Rob is highlighting where objects are persisting in memory until the end of the request and how memory spikes up, where a procedural solution resulted in much faster processing and lower memory.

That's not to say that you shouldn't create arrays of objects, but Rob's was a great test to demonstrate that objects, a lot of them, are problematic in ColdFusion. Interestingly, keeping the object in memory actually HURT performance. As this demonstrates, it's not the instantiation of objects that causes the problems, but the bean persistence. Objects holding data tend to be memory hogs, even in CF8.

Here is probably the most significant statement made in the series of posts:

In today's conversation, both of us agreed on this principle, but we haven't been working together all that long, so it was good to bring it up, and I thought I'd bring attention to the subject. Rob's blog posts on it hit home.

If you haven't found Rob's blog yet, I suggest you add it to your rotation.