I considered that approach, but if I did that in the session scope, and assuming I may have 100 users logged in at any time, that means I would be holding 100 instances of that data. After reading a couple of responses on the CFCDev list, I am rethinking my approach a bit. And before I move too much further forward, I decided I need to look into some of the ORM tools available and see how I can best leverage those. Nando also made the point that if I am using the objects for mostly getting rather than setting than it might not make since to instantiate them at all but use the gateways, and instead of persisting the objects, persist the gateways as singletons. This saves the resources of instantiating stateless gateways over and over. That right there would help a lot. I think I will spend some more homework time before I really make up my mind. Thanks for the input!
~Dave
Dave,
A couple of thoughts from an OO novice assuming you use CF 7 on a non-clustered application server – if you are using CF 6.1 this is possible but would take more work and if you are using a cluster of servers more yet.
- Unfortunately, we don't live in a perfect world and rare is the system where we can maintain all data in memory. Based on this premise, I would suggest loading the company information into session scope the first time the company data is needed. If the data can be loaded quickly I would load all relevant information for that company, if not I would load the pieces as needed by the application.
- Create an onSessionEnd method that when a user session is ending will save all changes made to the loan information unless it makes more sense to have a user triggered save operation.
One risk with this approach is that if you lose power to the server or reset ColdFusion you lose all updates that have not been saved. You can manage the reset ColdFusion by setting links to all your session objects in an application object which could then be used in a global save operation. I don't see any way around the lost data to a server failure with this approach and if you need 100% data reliability I would have the objects save any changes on user commit of the changes and skip the onSessionEnd code. The save on user commit approach would definitely be simpler to implement.
Hope you find these thoughts useful,
Tom
From: Dave Shuck [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 02, 2006 9:23 AM
To: Dallas/Fort Worth ColdFusion User Group Mailing List
Subject: [DFW CFUG] OO design question
For members of the CFCDev list, I apologize for the cross post, but I know not everyone here is a subscriber there. :)
I am refactoring an old loan origination application system and am going through the process of UML design, and mapping out the relationships of all of my objects. I am still somewhat new to OOP, but I have built several small OO projects now and feel pretty comfortable with OO concepts such as composition vs. inheritance, and have built several small OO apps. I have yet to build a really robust fully OO system. I am running into a stumbling block in my train of thought in a couple of areas and wanted to get some opinions.
Consider the following relationship....
A Company has Users (there are multiple companies)
Users (could) have Loan Applications
Loan Applications (could) have a plethora of their own properties of simple values and objects
I am considering building an application-scoped array of Company objects, each with a property of Users which is a structure of all users tied to that particular company, where each item (instance of a User object) would have its own properties/methods unique to that user. I have tested that in a small scale (adding/removing users) and it seems to behave like I would expect, so that part makes sense to me so far, but if you see any big things I am missing there don't hold back.
Now, my immediate concern is as follows: In listening to the Helms And Peters "Objects for maintainable code", I noted that Hal makes the comment along the lines that if we had perfect systems that could hold the objects forever, we really wouldn't need databases to persist the objects. If I understand that correctly, he is suggesting that all objects are loaded up when the application starts and the only database interaction is when persisting them. Am I understanding this properly? My gut feel (which is only slightly more than occasionally right) is that it seems unreasonable from a memory standpoint to hold every user in every companies' Users property(ies), and the properties/methods of each user within that, and the properties/methods within those, and so on to the end of the relationship tree. What is the best approach here, keeping in mind that I want to limit the database interaction as much as I can?
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.HostMySite.com
www.teksystems.com/
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.HostMySite.com www.teksystems.com/
