Hi Sasha, sorry it has taken me so long to get back to you. I've been putting a lot of thought into my response, and I would still like to think about the issues here a little more. Specifically, I want to evaluate using the iBATIS DAO layer instead of my own custom DaoManager. I will probably send a follow-up email in a couple weeks. Comments below... ----- Original Message ----- From: "Sasha Borodin" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, October 10, 2003 11:32 PM Subject: Re: Keeping Actions clean - separating actions from businessmodel from persistence
> What I'm trying to grasp is where it it best for the business object <---> > dao interaction to take place. OK, let's make an example, cause I'm having > trouble thinking abstractly tonight... > > An online store customer selects several products, clicks "check out", which > calls a CheckOutAction. From there: > > 1. The CheckOutAction retrieves a Customer and a List of Product's from the > session; it creates an Order out of those components; it then calls > placeOrder(Order) on a Store business class. > > 2. Store.placeOrder(Order) saves the Order to persistent storage; then uses > an Emailer business class to emailOrderConfirmation(Order). > > ----------now the question: > > 1. Which component is responsible for discovering the DaoManager, > retrieving the OrderDao from that manager, and telling the dao to save()? > Is it: > a. the Store.placeOrder() method? > -or- > b. the Order business object itself? If you get a copy of the Core J2EE patterns book that someone recommended, then the answer is "well, it depends". If you are using business objects as described in the book, the business object's job is to shield the rest of your application from the underlying persistence mechanism. It could do this using the DaoManager. However, I would still guess that Store.placeOrder() would tell the Order business object when the save needs to take place, and the Order business object would delegate this command to the save() method of the DaoManager. Otherwise the business object knows when to save itself... that sounds to me like a TV knowing when to turn itself on/off ;) > Is it the business entity object's responsibility to discover and use its > dao's, or that object's *user's* responsibility? > > Matt, you seem to forgo business entity classes and create DAO's right in > your action, passing those to business "use case" classes... Yes, that is exactly what I do for the sake of simplicity. The Core J2EE patterns book says that when the data model closely represents the domain model this approach is valid. > Mahesh, your business "use case" components seem to be the ones responsible > for discovering the right DaoManager implementation, and retrieving the > needed DAO classes... > > Anyone make the business entity classes themselves responsible for finding > and using their respective dao's (say, when an Order is issued a save() > command)? > > Thanks for all your input! > > -Sasha > > > On 10/10/03 20:25, "Sgarlata Matt" <[EMAIL PROTECTED]> wrote: > > > I have a 4 tier architecture. > > > > PRESENTATION TIER > > - Struts > > - Action classes > > > > BUSINESS TIER > > - Business Objects > > > > INTEGRATION & PERSISTENCE TIER > > - DAO Manager > > - DAOs > > - Other database access mechanisms (I do some JDBC using a fancy home-grown > > SQL building mechanism when dealing with particularly complex queries) > > > > RESOURCE TIER > > - Databases > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
