|
Hi Phil,
That helps, sure, BTW I'm using a lot the Mach-ii
info app and it really helps me with the FactoryDAO.
The fact is that maybe this should not be a Gateway
in the strict sense.
The article object has some other objects that are
properties of the article. (like images, or comments, for
instance).
These properties (Article.properties) belong to the
article, and are what I'm intantiating inside the loop.
And I need them as objects, that's why the gateway
loops over the properties (that belongs to the
article) and instantiate every one of them.
I'm really getting only one article with "some"
properties inside a struct, don't know if there's any other way of doing this,
I dont want arrays and a struct of realted objects
seemed a nice idea.
When it comes the time to get many articles I'll
have the gateway returning the query and will probably work on them as
recordsets, not objects.
I will move the DAO outside the bean, and have an
articleManager (or Listener) instantiating the bean and having it
populated, it's on my todo list.
I see that you populate the bean from inside the
DAO (in faqDAO you have the read mthod that does it with
arguments.faq.setFaqid(faqSelect.faqid) etc),
this didn't ocurred to me, I had my CRUD only doing
queries and returning them to the bean for being populated.
Any special reason for doing this ? Should the DAO
know about the setters and getters methods of the BO ?
I'll try to do the single DAO instance the
Mach-ii way, I already store my BOs in an application.
Thank you again for the help.
[]
----- Original Message -----
Sent: Tuesday, January 25, 2005 6:21
PM
Subject: Re: [CFCDev] How to avoid
duplication of objects
First off, the Gateway is designed to provide "aggregated
access" to
your data as opposed to "per object access" to your data.
It
addresses performance because you typically don't want to
create
objects for each row of your result set. By looping over your
result
set from the gateway and creating object instances your negating
that
so that's not recommended.
Number 2, you don't want your
business objects to know about
persistance. So your article shouldn't
have an instance of articleDAO
Read http://livedocs.macromedia.com/wtg/public/machiidevguide/models.html
for
more on this a typical design with BO,gateway and DAO.
As for only
having 1 instance of DAO, you'll typically have a
"manager" object in the
mix that coordinates your BO and DAO. In
Mach-II this is a
Listener. In the contructor (configure method), is
where the
reference to the DAO is and there is only one created since
the Listener is
only created once and stored in application scope.
Does that
help?
-Phil
On Tue, 25 Jan 2005 18:10:22 -0200, Marcantonio
Silva
<[EMAIL PROTECTED]>
wrote:
>
>
> Hello,
>
> This seems to be a design problem to me (but could also be ignorance)
and
> maybe somone can see a better way:
>
>
I'm working with a DAO and a Gateway for, lets say, multiple article
>
retrieve, I have a DAOFactory that instantiates the DAO depending on
the
> type (eg: MSSQL, ORA etc).
> I want a struct of article
objects, so what I do is send a getArticles() to
> the gateway, it runs
a query, loops over it and creates one object for each
> row, storing
them in the struct:
>
> [articleGateway.cfc
getArticles()]:
> cfset stArticles = structNew()
> [loop over
articlesGateway]
> stArticles[key] =
>
createObject("component","article").init(stConfig).getArticle(query values)
> [/end loop]
> return stArticles
>
>
> Inside the bean I init the DAO from the factory:
>
> [article.cfc init()]:
> cfset
variables.articleDAO =
>
createObject("component","model.factory.DAOFactory").init(arguments.stConfig).getDAOFactory(factoryType:arguments.stConfig.dbtype).getArticleDAO(arguments.stConfig)
>
>
> First I had this in the constructor, but then I
decided to move the
> "stConfig" from the constructor to the init, in
order to avoid
> duplication of the XML functions that are parsed
everytime I instatiated the
> config.cfc.init() method
>
(actually, I got it under the application scope, but didn't feel right
to
> have dozens of calls to the method, so I decided moving it with
every call
> to init methods on my app, like Mach-ii dos with the
appManager).
>
> The problem is that everytime an
articleBean is instantiated it has to call
> the DAOFactory, and
eventually this will start decreasing performance at
> runtime.
>
So if I have to instantiate, lets say, 20 articles, I would have to init
the
> DAOFactory 20 times, it dosen't seem right.
>
> To resolve the problem, I could instantiate the DAO once, and send it
to the
> init() method of the article everytime, but this seems an
overkill:
> (eg: stArticles[key] =
>
createObject("component","article").init(stConfig,articleDAO).getArticle(query
>
values)
>
> I would also have the article bean
init() depending on receive the DAO,
> which I don't want, since
sometimes I want to create a blank article,
> or even an article
populated by a form, and I dont need a DAO for doing
> this.
>
> What I could do, if I could use my old CF skills
woul be:
>
>
> [article.cfc
init()]:
> <cfif NOT isDefined("request.articleDAO")>
> <cfset request.articleDAO =
>
createObject("component","model.factory.DAOFactory"). ... />
>
</cfif>
> <cfset variables.articleDAO =
request.articleDAO >
>
>
>
This way I wouldn't have 20 instantiations of the DAO, but it doesn't
seem
> right too ... I shouldn't be allowd to use the request scope,
should I ?
>
> I guess this could be done with a
singleton for managing the DAOFactory, and
> instead of creating it
everytime I could get it from the singleton, but is
> this right design
?
> Is there any better way of doing this ?
>
> []s
>
>
>
> Marcantonio
Silva
> Product Development - ContentObjects
> [EMAIL PROTECTED]
>
www.contentobjects.com
>
Phone: +55 11 3055.2004
> Mobile: +55 11
7732.4907
----------------------------------------------------------
You
are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words
'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by
CFCZone (www.cfczone.org) and
supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the
CFCDev list is available at www.mail-archive.com/[email protected]
|
