A while back we were working on a huge new website in ColdFusion which was a rearchitecture of an extremely mature but very worn out code base. One of the biggest things we wanted to do was adopt a substantially more object oriented approach to development as the original site was started in the ColdFusion 4.5 days.
However we very quickly ran into the problem that many ColdFusion developers have faced (in fact there was even a session on this exact subject at CF.Objective() this year). ColdFusion objects have a substantial overhead to instantiation. Java programmers create hundreds or thousands of disposable objects for even fairly simple tasks. They create objects for things they don’t even realize they’re creating objects for (ints, Booleans, Strings, even lots and lots of Char objects as a string has a Char array in it with one object for each character in the string).
ColdFusion developers can’t be so cavalier with their object creation though. Of course under the surface of ColdFusion is its Java runtime, and so there are plenty of Java objects created under the hood, but when it comes to ColdFusion components, you really need to limit how many you create.
If you try a traditional bean approach to programming in ColdFusion (one data container object for each distinct thing you’re working with – eg one for each query row in a result set), you’ll discover that your application quickly crawls to a halt under any serious load. ColdFusion simply cannot afford the overhead of creating so many components.
There are two main approaches to solving this problem. One is aggressive use of caching of components, and sharing components between users. This is not really a bean approach, at best it could be considered “inspired by,” and it raises quite a few complications of its own, including increased memory footprint, and dangers introduced when one user is modifying a shared object while other users are using it.
The other (and the one I prefer, but it’s a bit less convenient) is to create your beans in Java. Here is a simple bean:
The advantage of this approach is that you can create tons and tons of disposable copies of this object with very little performance penalty. In fact it should be no more expensive than creating a Struct of properties – but you get the benefit of type safety and guaranteed properties. You can also add convenience functions like:
This way you can:
and get “A 1999 Chevy Cavalier. This was not my first car.” as your output.
Coming soon:
- How to build and bundle your beans
- Using the Java enum construct for enumerable properties
Recent Comments