> I'm modeling my Objects after my database structure. Each object > represents a table. Whenever I instantiate the object I pull all the > information about the object together. I think this is a little > overkill; I'm just playing around to see what I can do with it.
> What rules of thumb/guidelines do you go by when modeling your objects? > Do you base it upon a table structure, or perhaps how the objects > interact with each other? Tapestry was designed to allow multiple content types ( classes ) in the database, but without having to change the database structure ( using xml ), so when Tapestry reaches MX there will probably be one component for each content type even though all the object data is stored in a single table. For most databases however, I'd hazard a guess that one class per table ( discluding lookup and cross-reference tables ) is a good rule of thumb. Creating classes for cross-reference and lookup tables is liable to create more overhead than provide no real benefit. > My initial guidelines are something Hal Helms > mentioned about objects. He said to the effect that an object should > contain everything it knows about itself. For instance, a person knows > his/her name, age, birth date, sex, etc. I would go a little further in saying that an object should encapsulate some things it may not necessarily have known about itself... i.e. A person doesn't know how their autonomic nervous system works, but if we were going to create an object which would encapsulate a person, it should include a series of functions which would represent the behavior that the nervous system exibits. In some cases, these "unknown subsystems" might well be modeled by other objects which are contained within the larger object -- a person for instance might contain circulatory, nervous, skeletal, respiratory and digestive sub-objects which know little or nothing about each-other's inner workings, but take and give out certain materials in order to keep the body working. The respiratory system for instance, would take in air, internally remove everything but the oxygen which it passes on to the circulatory system as it expells the remaining content of the air back out of the body. Removed from the body, the respiratory object would be useless ( not to mention just plain gross! ) but encapsulating its properties and behaviors will allow you to keep the person class small and allow you to work on it at a higher level without worrying about the internal workings of the lungs. Plus, if you decide later that you need another kind of animal, say a dog object, you can likely reuse the same respiratory class used to create person objects to create dog objects. > So, I instantiate an object by > passing its unique ID into a method. I then go through the database > structure and pull the data I can "find" for that ID into the object. > This seems like a lot of overhead because I have to pull all of this > data together for each instantiation. I may only use part of the data > available to me at any one point in my application. How does CF manage > the data pulled together for an object? Is it stored in memory? I would expect it's stored in memory. I've been told you can create components in persistent scopes, i.e. session or application, so if you create an object as a local variable or as a request variable, it would be destroyed at the end of the page request as a matter of garbage collection. If you create it in a persistent scope, then it should hang out in resident memory until that scope expires. If a given piece of information about an object is used infrequently, then you may want to leave that peice of data alone ( not pull it in when the object is instantiated ) until it becomes necessary and then use a private function to return that data to other functions or methods within the object. hth S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ------------------------------------------------------------------------- This email server is running an evaluation copy of the MailShield anti- spam software. Please contact your email administrator if you have any questions about this message. MailShield product info: www.mailshield.com ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
