If you missed it, Jeff Chastain put up a very interesting post over at Alagad's Blog. Also good was the "spirited" discussion that followed between Barney and Peter Bell. I don't know how I feel about all of it, but the entire thing is very fascinating.I've been wrestling with the same concepts recently. It seems a lot of CF OO design patterns don't seem very object oriented. At least not compared to the OO stuff I've seen in Java code. I've seen Java patterns where your DAO is the only thing that ever sees a result set. Your business logic and display all just deal with collections of objects. Of course, Java can instantiate a few trillion objects and not break a sweat. CF8 is allegedly over 20 times faster than CF7 at instantiating CFCs, but apparently still not fast enough to make everything an object. So what do we do? We create gateway objects that simply return a result set. Or IBOs (Iterating Business Objects described in the Alagad post) to handle umpteen theoretical objects with one actual object. I definitely like the IBO approach over the gateway which often times feels like a pseudo-OO skin wrapped around some procedural code that does the same basic thing an inline cfquery tag would have done for you. The IBO allows you to still encapsulate any special login in getters and setters. There are benefits to the gateways too I suppose. We do get the encapsulation bonus of having all the code in one place, and SORT of abstraction from our database. Of course, when you deal with a result set, you are pretty much tied to your database schema anyway. This doesn't bother me that much though. I don't know that I subscribe to a lot of the talk around a DAO separate from your business logic. I'll believe the whole "you can change your database around and not bother your middle tier" thing when I see it. Seriously-- how often do people move from a flat text file to xml to MySQL, and how often does a column get renamed for the fun of it? I modify my data structure regularly-- but it is because the business model changed which means middle tier change is inevitable regardless of a DAO. At least all my queries are in the same place... My other problem with objects is I seemed cursed to be doing basic CRUD 90% of the time. The result is a pile of beans that do nothing. Well, don't forget the obligatory getters and setters, but onmissingmethod can make light work of them. One of the much heralded benefits of your getters and setters is when you have extra logic around the access of data. For instance a getAge() method which calculates age on the fly from the birth date field and today's date. That's a wonderful example, but I seem to only have 1 of those for every 100 fields that my bean just robotically serves up without touching. Have I saved myself any trouble by creating a CFC to encapsulate a query row when it doesn't do anything the query wouldn't? I'll tell you what it does-- it gives you one more layer to go back and update when you add a new column to your database. :) Yeah I'm being heavy-handed, but bear with me. I haven't given up on OO by any means; I'm just venting stuff on my mind. Here's my other problem with objects: AJAX. Despite the bridges that have been built (cfajaxproxy, AjaxCFC, JSON, WDDX). There is still a gaping chasm between my web server and the browser. In the simple old days, I could just create my HTML on the server and send it off to the browser. The browser was dumb and it was ok. Now, we have RIA web 2.0 value-added crap, and suddenly the client needs to know things. It needs to take data and figure out what to do with it. Communication of basic constructs like strings, arrays, and structs are pretty easy with WDDX and JSON serialization, but my CFC instances are still back on the deck of the server waving goodbye as the HTTP boat cruises away. Apparently they are too complex to get on board, and they don't speak the destination's language anyway. In my utopian dream world, I should be able to have a cfgrid and bind it to an array of objects and define the getters to call for each column. Cfgrids only bind to structs or result sets though and it's impossible to get an instance of a CFC to the browser anyway. The data might fit into a struct, but the logic-- well that's unfeasible. I could manually create a JavaScript object that matched my CFC (to the extent possible) by duplicating JS code for the equivalent getters and setters, but there's no direct way to create and populate it and I don't think it would be worth the time to do so not to mention the duplication of code. Further to that point, representing has-a relationships can be tricky too. The data part of it can probably fit nicely inside of an array of structs contained in a struct, but should I hit up the database, create an representation of the data with CFC's containing instances of other CFC's, and then turn it back into array's of structs so it can be serialized for the browser or do I just skip the CFC instances all together and just go straight from database to the serializable structs? The latter seems like the obvious answer, but I don't feel like there's anything truly OO about that, other than the fact that the logic to do so might have been stuffed inside a cffunction. Well, this is the part of the blog where I usually say "I digress", but I'm not sure if I was ever on a track to begin with :) I just had to get some stuff off my chest. Mostly frustrations with trying to decipher what is really OO, how to do it with ColdFusion (and Ajax), and the constant restrictions that make me code things in a way that feels wrong (or at least procedural). Feel free to share any answers to the universe you have. Except 42-- I already know that one.