Re: [CFCDEV] How many objects is too many?

[Nando]

Jaime, My line of thinking here is pretty simple, but i think it's in line with best practice in CF. If you simply need to display the data to the user (probably as a list), use cfquery, a ColdFusion query object. If your users need to work with the data, then go with business objects, DAO's, etc. The simple fact of the matter is that a user will not be able to edit 1000's of entities at the same time. I see the usefulness of an object most clearly when you need to both maintain state and manipulate the data, during an editing operation for instance. And i don't see the possibility of needing to instantiate hundreds of objects in one go unless you're working with data, specifically a list of records. As far as your service layer goes, well, you're probably going to instantiate that and cache it in application scope, using lazy loading wherever possible. Practically, if you've got 100's of objects in your service layer, i'm pretty sure they won't all be needed on the first page load. Another possible way of minimizing the overhead of object creation is to represent the data packets only as an array of structs if you're more comfortable with that rather than a query object, and populating a full blown business object as necessary from the array of structs. Translating that to the world of transfer, at it's current level, means to me that transfer isn't well suited to display lists, for instance. Better to use your own gateway for that and return a query object, possibly caching it with your own mechanism if needed. Or use the new "Transfer Query Language" feature Mark is working on instead of your own gateway. I'm sure your use cases are more complex than i've represented them here talking about lists and edit operations, but as far as i know, this is the general approach to use in CF for performance reasons. Jaime Metcher wrote: Hi,   When you're modelling your application, how much attention do you pay to minimizing the number of objects instantiated?  Obviously CF has a higher object creation overhead than some other languages.  OTOH, the gist of much OO practice (and many patterns) is to create lots of fine grained objects.   I often read that a typical noob error is creating too few objects with too many responsibilities.   So, how often do you find yourself thinking "well, in Java or Smalltalk I'd do xyz, but in CF I'd better not because I'd end up with too many objects"?  Which is another way of asking to what extent we need to modify existing OO practices to allow for CF's limitations.   A couple of points of reference: 1. This post was prompted by a discussion with Mark Mandel on the transferdev list.  I'd spotted an issue purely because of the massive slowdown that occurred when 700 objects were inadvertently created.  That issue has been resolved, but it left me wondering, if I can't instantiate 700 objects how many can I create?  10?  50?  This has huge implications for how we architect our apps.   2. I have a Dolphin Smalltalk image that, from a fresh install, reports instantiating 160,000 objects.  Obviously with an object system this slick you don't worry much about throwing in a few hundred more.  Given that CF's comfort zone is probably a couple of orders of magnitude lower, maybe a lot of the standard advice on OO design just doesn't apply to CF?   Any thoughts appreciated. Jaime Metcher You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org