That makes sense...it's just hard to get out of the mindset of having queries, etc., attached to the specific display templates they provide data for.
If a display isn't displaying data correctly, I always know that query is part of the same page as the display code. However, I will say that I have recently attempted to put all my processing in a template and use CFSWITCH / CFCASE to process info because I wanted the user to stay on the same page of an app (an attempt to emulate desktop software) for working, even though it required trips back and forth to the server/database. Keeping things visually simple is key for this client and I wanted to avoid changing pages as often as possible. So there is a lot of links with ?Action= attached to them and sent to a main processing template where processing was done according to the definition of Action... While it was simple to know where all the processing queries were located, that page was beginning to become a bear to maintain and track what was going on. I found thee was something to be said for keeping the processes attached to their relevant displays when they process only affected on particular display... Rick > -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 12:22 AM > To: CF-Talk > Subject: RE: OOP, why me? > > > > Yes...thanks, Isaac, for taking the time to > > "water it down" for me...it makes more sense now. > > > However, the big question for me remains...what is > > the benefit for learning what almost amounts to a whole > > new language? Just reduced code? Faster execution? > > I'm sure it's faster, but how much so? > > Performance benefits (faster execution) are nebulous and difficult to > quantify because it often depends a fair amount on how you structure > your code. It's entirely possible (easy even) to write inefficient OO > code that would not perform as fast as some equivalent but well > designed procedural code (using cfmodule tags or includes). There is a > noticeable performance gain from using objects which are being stored > in memory, partly because the server doesn't have to continually > connect to the database to get their information (if they require > information from the database), and partly because there are processor > cycles eaten up when the object is created (although something very > similar happens when a custom tag is called with cfmodule). > > For myself, the big benefits are mostly in terms of reduced code, > easier to read / more legible code (sometimes even > "self-documenting"), shorter development cycles (less code means less > typing and of course, more legible code means less time spent > scratching my head about why I wrote a particular line). But also > because there are some things (and I won't get into them because that > was part of the problem with my first reply :) that would just be > darned difficult to accomplish without an object (the listeners on my > SQL Select objects I mentioned in the first post are one salient > example). > > > This seems like a whole new programming paradigm > > to adjust to...and like all good business people, I have > > to question the ROI...how much better off will I be for > > investing more dollars and time into learning these > > new techniques? If I'm not building apps that require > > extreme capabilities and processing tons of data, and > > my apps are simple retrieve, insert, update, and delete > > queries for relatively simple apps...how much difference > > would all this make? > > Personally I don't think it requires "extreme capabilities" or > "processing tons of data" to see a benefit from OO. For that matter, I > don't think OO inherently really does anything for "processing tons of > data" -- it may help with "wider" data, but not with "a greater > abundance of the same narrow data". (Not sure that makes much sense, > but in essence I'm saying they may help with more complex database > schemas, but not so much with simpler database schemas that happen to > be filled with more data.) Anyway... I'm getting off into the > essoteric again. :) I think it's possible to see some benefit from an > OO architecture with very little effort. The simple matter of having > all your database access in one place instead of spread out into lots > of different unrelated templates is helpful in itself, if for nothing > other than organizational reasons. It's nice to always know exactly > where to go if you have a problem with a query, and it's very nice to > never see an ad-hoc query copied and pasted between 2 templates. > > s. isaac dealey 434.293.6201 > new epoch : isn't it time for a change? > > add features without fixtures with > the onTap open source framework > > http://www.fusiontap.com > http://coldfusion.sys-con.com/author/4806Dealey.htm > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234409 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
