I always strive to keep any sort of construction code out of a bean.
A instance of a person shouldn't, IMO, know how to persist itself... which is why you'll often see controller/listener events in my applications called savePerson or persistPerson, and the associated methods will have function calls like savePerson(person). I'll compose DAOs into the controller and use the controller to make the calls to the persistence machanisms, passing beans and into them.
Somehow, to me, seeing personInstance.persist() feels wrong, because it gives the bean more work to do than it should have... after all, a bean is a container for data, not a business object. The DAOs are responsible to save the data, the beans are responsible to carry them around... so the options I see are to write a generic manager class that gets composed into the controller if you're opposed to having the controller actually do work or just code the controller around the model so that it's got direct access to the model classes and let it do the same thing, just one less layer of abstraction.
The thing is, if your controller is already responsible to take a form post, get a bean from the form data, and then call a persistence scheme to save the data, the only distinction between wrapping the code up in a manager and having the controller call it or just letting the controller do the work is how portable your code needs to be. Some things I write are likely to be deployed under MachII, ModelGlue, or Fusebox, so it's in my best interests to have something contain the actual code that does the work... so the controller just makes method calls. That enhances code reuse and reliability.
When I write things that I have more control over, I'll save the complexity of the manager class and let the controller actually do the work itself... but either way, it's doing the same thing. It's just a matter of how you organize it.
Since the process of creating an object is fairly static and it's likely that you're going to have the same object created in different places, you're going to benefit from having the creation code in the application scope. Putting your creation code there and coding the factory classes (or manager classes, although classically "manager" is not the same as "factory" - managers maintain the state of their composed members, factories just create them and hand them back to the caller) to simply return them is probably the best way to go.
Laterz,
J
On 7/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
I have my objects divided into BO, DAO, Gateway and Manager Object. Many
of my objects are composed of other objects. For instance I have a User
object which is composed of a Person object and an array of Company objects
they sponsor. I'm trying to figure out the best place to load my Person
object from the database when I instantiate the User.
In my UserManager I do the following
<cffunction name="load" returntype="objects.user" hint="I load a
user into memory" >
<cfargument name="person_id" type="numeric" hint="I am the
person_id of the user">
<cfset var myUser =
createObject("component","objects.user").init() /> <!--- returns a blank
User Object --->
<cfset myUser.setPerson_id(arguments.person_id)>
<cfset variables.userDAO.read(myUser) /> <!--- loads some data
such as their security profile --->
<cfreturn myUser />
</cffunction>
Now, I need to load the person information from the database. Ultimately
the code that knows how to do this is in the personDAO. I have a method
that returns a Person object from the person_id in my personManager (which
is instantiated in the application scope). It could be called with the
following:
application.personManager.getPersonByPersonId(arguments.person_id)
Should I call this method in the UserManager above, in the UserDAO's read
method or in the User object's setPerson_id() method?
Should my UserManager, UserDAO or User object know about the personManager
in the application scope or should I just go ahead and instantiate it
locally in the method or in the variables scope?
Suggestions?
Jason Cronk
[EMAIL PROTECTED]
--
---------------
-------------------------------------
Buy SQLSurveyor!
http://www.web-relevant.com/sqlsurveyor
Never make your developers open Enterprise Manager again. ----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
