Hi Brian, Thanks for answering I missed Baz¹s question . . .
Baz, There are a couple of things I do. Firstly, if you want to display a list of 100 objects, I actually just instantiate a single bean which provides an iterator (I called it an Iterating Business Object for the lack of another term in the CF world) - there¹s a project somewhere on RIA Forge with sample code. The benefit of this is you can still get and set properties, so you can encapsulate your getting and setting logic within the bean, but you only have to instantiate one bean, not 100 which (at least in the past) was a real benefit in terms of performance. However, I also take it a little further. I have the concept of ³custom data types². Think about how much time you spend creating code that¹ll display currencies correctly, that¹ll allow you to enter phone numbers in three text boxes instead of one and that merges those three text boxes from a form into a single field. Then add in any transformation code (to strip all non-numeric characters from phone numbers, for example) and then the validation code (validating dates are well formed, that phone numbers and cc numbers have the right number of digits and so on). With custom data types, you can just say that a given property is a Date or an Age or a US Phone Number or a WYSIWYG and they system will automatically provide smart, parameterizable form fields, display code and form processing code for handling it automagically so you can declaratively describe most of your property specific rules and the framework will dynamically run the appropriate code. In an ideal world, I¹d create an object for each property (so if User had firstname, lastname and Email, each would be an object) and each property would extend the appropriate custom data type class (that¹s how I¹m looking to implement a Ruby version of my framework when I get some time). In CF, within my bean I inject a DataTypeFacade singleton which I pass the data type, the method type and any related parameters. It has all of the singleton custom data types injected into it so you can reuse property level code without having to instantiate an object for each property. It¹s a little hacky, but all of the design decisions are encapsulated within my base business object so it¹d be easy to change and the performance implications in CF of having a CF object for every single property of every object are extreme enough that I¹m happy with the solution from a pragmatic perspective. Best Wishes, Peter On 11/12/07 7:29 PM, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > If I recall correctly, Peter loads up all the data into the object, but then > allows you to treat the object like an iterator, where each loop iteration > loads a new row of data into the object. So even though there is only 1 > instance, it keeps getting repopulated as you loop over a set of data (query, > array, etc.). > > On Nov 12, 2007 6:06 PM, Baz <[EMAIL PROTECTED]> wrote: >> >> @Peter >> What you wrote is very interesting. When you say you use singletons to >> enhance performance, where do you store the specific instance data for >> each property? Are you, perhaps, storing the metadata for each >> property instance locally in the singleton in a native cf type (i.e. >> query) then using that metadata to pass into the functions when >> needed? >> >> Cheers, >> Baz >> >> >> >> On Nov 11, 2007 6:41 PM, Brian Kotek <[EMAIL PROTECTED]> wrote: >>> > As always, it's a trade-off. In this case, if the advantage of having >>> email >>> > wrapped up into its own class is very high (perhaps the behavior of email >>> is >>> > expected to change often, or needs to be reused in many other classes), >>> then >>> > that advantage is worth the performance cost of creating it for the >>> objects >>> > that need it. However, I wouldn't just go do this with all properties of >>> all >>> > objects. It has to be done for a valid reason, with an understanding of >>> the >>> > pros and cons. >>> > >>> > In general, small classes ARE preferred. Smaller objects are much more >>> > likely to be cohesive. The larger an object gets, the more likely it is >>> that >>> > is might be doing too much and the more likely that future changes will be >>> > more difficult to make. >>> > >>> > >>> > >>> > >>>> > > >>>> > > >>>> > > >>>> > > >>> > >>> > >>>> > > >>> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
