That seems to make some sense. These Statements and their Visits (and Visits having Transactions which I left out for simplicity) are coming from parsing a text file but that's not much different than a form. What is the primary argument for pulling these methods into a Factory instead of having them in the Service? Primarily encapsulation to keep the Service cleaner? I'm injecting the DAO and Gateway into my Service layer right now. I presume I'd just move that to the Factory and then inject the Factory into my Service. That sound correct?
Judah On Wed, Feb 18, 2009 at 1:12 PM, Brian Kotek <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
