Dave,
In
answer to "Does that make sense?" - I can't really say at all. We'd
really need to sit down together and look at the application in detail,
getting down to each individual screen that will be presented to the user and
it's function. Even then, a lot of different options might make sense, depending
on the critera we were working within.
But
in general, i've rarely persisted business objects in application scope in a
collection. That seems like it might be "unnecessary" to me. There's no problem
with doing it! You can certainly instantiate an array of Company objects,
compose them inside another object, and get at them with
someAppPersistedObj.getCompaniesArray() to display them, but it will be
unnecessarily heavy. You can also simply use a gateway, query the company table
for the data you need, and cache that in someAppPersistedObj, and make it
accessible with a getCompanies() method that returns the cached query object.
(I'm assuming, maybe wrongly, that you only need display capability when dealing
with all the companies at once in your app.)
Unless i need the functionality of a bean or a business object, the
getters AND setters AND any other methods that might manipulate the
data, i wouldn't use a collection, an array of objects. That said, certainly
sometimes you DO need it. If i had an app that tracked and presented stock
prices for instance, and needed the ability to update the price
fluctuations moment by moment, and deliver them out to my users on demand
in real time, then perhaps an array of stock objects with heavily used
setPrice() and getPrice() methods would be perfect for the job. If those prices
are changing all the time, there'd be little point in persisting them to a
database and then getting them from the database.
But
i don't think the company addresses and phone numbers are changing every few
seconds. ;) And if we think practically about it, if they are only
displayed on a contact us page or something, it would be just fine if they were
persisted in the database (not in memory), and fetched with a gateway call. I
wouldn't necessarily persist stuff in memory unless it was accessed very often
and you needed a performance boost.
That
said, if you've got various gateways to fetch your data, it might make a lot of
sense to persist those in an application scoped Factory, and then you'd
have something like
application.GatewayFactory.getCompanyGateway().findAll()
to
fetch your company information.
There's no GatewayFactory in your pure conceptual model - you wouldn't
even know where to stick it in if you started building out the pure conceptual
model and suddenly decided you needed a gateway object to get at your company
data. (Which i why i lean toward the implementation perspective more - it's more
practical, and you easily find room in a model designed around the
implementation perspective for the practical stuff that comes along later as you
build the app out.)
If
you look from the implementation perspective, then we know that instantiating
gateways for each page view over and over again is a waste of server resources.
So it makes sense to cache the gateways composed inside an application scoped
factory. Since they are stateless, we can just instantiate them as singletons
inside the gateway factory and very efficiently get at the data in the database,
because our SQL is held there in memory in the gateway. You get efficient
use of both memory and processing power in this way.
You
see how different the implementation perspective "thinks". It really thinks in
terms of "What does the application need to accomplish here and how can i use OO
to do that better."
That's not to say i won't have a Company object. I will, if i need to
edit Company information (well, i might not need to build it out if i'm using
ARF!, but it will still be there, just produced by the ARF! framework).
And
that's not to say i would never wind up with an array of objects composed within
another object, a collection. But again, i'd only do that if it was functionally
needed.
Everything i'm saying here is "in general". Without really sitting down
with you, i have no idea what the "right approach" might be. Keep in mind that
probably everyone on this list with experience would implement your app
differently - perhaps very differently - from each other! (And we'd all probably
do it differently from ourselves in 6 months!)
:)
nando
---------------------------------------------------------------Original Message-----Yes Sean, we are looking forward to your visit here in DFW in Feb, and I was really glad to see the topic. My wife and I have a baby due on the 17th so we'll see if that works out, but I hope to catch your preso.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Dave Shuck
Sent: Monday, January 02, 2006 8:19 PM
To: [email protected]
Subject: Re: [CFCDev] OO design question
Nando, thanks for your input too. Considering there will be some Loan Applications in the system that may no longer have any relevance (submitted loans stay in the system for X days), it wouldn't make a lot of sense to load them all up knowing that they would likely not be touched again. I may take the route of keeping the Company objects in memory, and loading the users into the Users property (possibly for user authentication), but may only instantiate Loan Applications within the Users objects if they log in or are needed by some other place in the system. Does that make sense? The only thing I can see as a potential pitfall there is if some other part of the system expects something that may not be instantiated, which I suppose this could be managed fairly simply.
~Dave
On 1/2/06, Sean Corfield <[EMAIL PROTECTED]> wrote:On 1/2/06, Dave Shuck <[EMAIL PROTECTED]> wrote:
> Sean, thank you for your reply. To answer your first comment, I typed
> "array" but meant structure for the reason you suggest. Your keen eye is
> appreciated though. :)
Cool.
> I keep seeing Arf! mentioned (and the others to a lesser extent), but have
> yet to go explore them. I guess today may be a reading day.
Joe did some great little videos showing how to use Arf! and there's a
Quick Start doc in the download. Transfer is the only one of the four
frameworks that caches objects in memory. Reactor caches database
object instances (metadata, essentially, not actual application data).
Arf! and objectBreeze do not provide caching.
If you happen to be near PDXCFUG, Austin CFUG, Dallas CFUG or Denver
CFUG, I'll be bringing my "Objects & Persistence" talk around where I
go into each of these frameworks - and will have a simple application
showing each one...
Nando's reply is important too - consider what you actually need the
model to do for you first and foremost, then figure out what you
really need in memory at any one time.
--
Sean A Corfield -- http://corfield.org/
Got frameworks?
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
