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
