You could use the Memento pattern and have
the memento itself only carry the common attributes of both the Bean and TO.
Or you could use Inheritance and have a
base class that encapsulates the basic functionalities of both the TO and the
Bean and then have each of the objects extend the base class with their unique
methods. Then you can pass around that base class as a type of memento.
Each of the derived objects can have a method which accepts an instance of that
base class as an argument and then uses that object to populate itself.
This way, a bean can be passed to a TO, a TO can be passed to a Bean, and they
can both be passed to other instances of the same type.
Object
ObjectBean Extends Object
ObjectTO Extends Object
ObjectBean.fill(ObjectTO_O_rObjectBean As Object)
ObjectTO.fill(ObjectTO_Or_ObjectBean As Object)
Or you could implement a factory pattern.
It depends on how flexible you want to get
and how you prefer to work with objects.
Roland
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bill Rawlinson
Sent: Friday, April 01, 2005 4:49
PM
To: [email protected]
Subject: [CFCDev] TO, Beans, etc.
The majority of the time my application needs a readonly copy of an
object, a plain vanilla TO
sometimes I need a mutable object (a bean with setters) but this is far more
rare
for instance most of the time folks are just viewing information about the object
so a TO is perfect, it can be populated from the database, no validation on
output needed,
and displayed. However, before saving or updating an object with new user
input I need a bean to populate, and validate against. As some of my
beans are fairly large I
thought, for performance concerns, that passing a TO around, and not a full
Bean, would make more sense in the majority case of just viewing the object.
as I refactor (I was always passing the full Bean) I'm trying to decide on some
things. first off should my DAO populate a TO and then, if necessary
create a bean from the TO OR should I build a bean and have it return a
TO if necessary. Currently my Beans have the methods setFromTO() and
getTO() available publicly so either path would be fine - though at the moment
I am always building the bean and calling getTO() - which seems, to me
wasting resources.
Also, when I call my manager object to get either a bean or a TO should I have
two separate method calls, one that gets a readonlyObject (TO) and another that
getsanObject (bean)?
or should I have one method with a boolean argument of readonly and I return
the corresponding object based on that (thus forcing me into a return type of
any - not particularly nice).
I really don't like having the "pattern" name in the method call such
as getObjectTO() or getObjectBean()
so, what do you think I should do?
1. should I build a TO and only construct a bean from a TO when I actually need
a bean (or leave as is, creating the bean and returning the TO).
2. should I have two different methods of some name where one returns a bean
and the other a TO or have one method with a readonly argument?
thanks in advance,
Bill
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
I have 47! gmail invites,want one?
----------------------------------------------------------
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]
----------------------------------------------------------