Either way, I would use a factory. The factory is responsible for constructing the Statement and its Visits.
So for new statements based on form data, your service would do statementFactory.buildStatement( statementData ), which will create and populate a new Statement object and return it. You can then do dao.save( statement ) to persist it. This assumes that a Statement is created before any Visits are associated with it. Otherwise you'd want to pass the visit data as part of the statementData to the factory, and let it create the Statement and it's Visits. For loading an existing Statement and its Visits, you could either do statementFactory.getStatement( id ), and let have the factory invoke the DAO to load the data and populate the objects to return. Or you could do dao.load( id ), and let the DAO invoke the factory. As you'll quickly see, when it comes to building and persisting aggregated objects like this, it can get quite complex. Which is why something like Transfer is so popular since it lets you skip all that work. On Wed, Feb 18, 2009 at 3:50 PM, Judah McAuley <[email protected]>wrote: > > I'm using a Service/Gateway/DAO/Bean model in ColdBox at the moment. I > know that an ORM like Transfer can help make my life a lot easier with > composition but I want to make sure I can do the theory to practice > part myself before I introduce a new tool to make things easier. My > current issue is figuring out where I place the functions to create > and retrieve child objects. > > This particular situation is creating a Statement. Statements have > some top level information like outstanding balance, patient name, > service address, etc. I have that being created and persisted fine. > Now each Statement will have one or more Visits. I have my > Bean/DAO/Gateway for dealing with Visits. Now, how do I (or rather > where I suppose) add a Visit to a Statement and then later retrieve > it? > > My logic tells me that in my bean for a Statement I'm going to need to > have a container that I will put my associated Visits into. Presumably > an array of either the id's of the Visits or the objects themselves. > I'm leaning toward an array of objects as I won't be dealing with a > huge number of Visits for each Statement. > > That logic would then give me this: > > Create a Statement with an empty array of Visits in a variable called > visitCollection or some such. Save the Statement to the database, get > the id back from the newly inserted row, set the id of the Statement. > > Populate a Visit bean, passing in the id of the Statement object, save > the Visit to the database, fetch the id back and populate it into the > Visit, then call a method to addVisit. That function should, I think, > live at the Service level. And I would think that it would take the > Statement object as an argument and the Visit as an argument and then > do an ArrayAppend() on the visitCollection and tack the Visit on > there. Since this is an action that isn't taking place at the database > level it shouldn't happen in the DAO or Gateway and the Statement bean > should only know about itself, not the details of its children, right? > > And then when I am fetching a Statement from the database, I would get > one via its DAO which would populate the bean and generate that empty > array for visitCollection. Then I would have a getVisits method in the > Service that called the VisitGateway, fetch the Visits, loop over the > result set and use addVisit again to populate the visitCollection. > > That sounds correct? Thoughts or improvements? > > Thanks, > Judah > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
