On Wed, Oct 29, 2008 at 9:48 AM, Anil Gangolli <[EMAIL PROTECTED]> wrote: > > Christian: > > You need to check which spring bean definition file you are using to define > your daos and which one you are using to define your managers and what's > getting included in the webapp application context spring bean > definitions. You are probably exposing the manager bean definitions up to > the webapp spring bean context but not the daos. > > But that's not really all. There is a key difference in their treatment. > In the default AppFuse setup, the transaction boundaries surround all > manager methods and this is done using Spring aspects using a line like: > > <aop:advisor id="managerTx" advice-ref="txAdvice" > pointcut="execution(* *..service.*Manager.*(..))" order="2"/> > > On the other hand, the DAOs just expect the transaction to be there and > there is generally no corresponding aspect. This seems to be the main > difference in how they are treated. If you directly access the Dao, you'll > also need to redefine where you have these transaction boundaries. > Conversely, if your controller calls need to call multiple managers it is > likely that you will also want/need to initiate transactions at the level of > the Controller or higher. > > One thing ill I've found about the tutorial setup is the unusual 1-1-1-1 > pairing of controller, manager, dao, model object. It's fine for a simple > tutorial, but rarely appropriate for a real app. If you continue to > develop that way, you will likely hit problems with the default transaction > boundaries as well as with the pain of dealing with all of the classes. I > think Matt comments on this somewhere, but I can't find a reference right > now.
Reference: http://appfuse.org/display/APF/AppFuse+Maven+Plugin <quote> Stop and think before generating code! At first, I didn't want to add a code-generation feature like this because you end up with a 1-to-1 relationship between tables/pojos, DAOs and Managers. On most of my projects, I have far fewer DAOs and Managers than POJOs. </code> ;-) Matt > > Generally I use something like: > Controller per action/view/form. Many more of these than managers. > Manager for an entire service interface. Each method may interact with > multiple DAOs. Each method is an entire service-level operation. Quite a > few more of these than DAOs. > Each DAO manages a single primary model object, but may in some cases > also manage its child entities for hierarchical types (e.g. > master-detail-subdetail with cascading). > > If you develop along these lines, you probably will feel less need to expose > DAOs directly to controllers. > > --a. > > Christian Decker wrote: > > I personlly don't see the difference between a Manager and a DAO from the > purely bean perspective, as they both as simple beans that are passed to the > controllers. I think in my case it would be a bit of an overkill to try to > create Managers, as I do not intend to create alternative frontends, other > than a Spring MVC frontend. > > > Regards, > Chris > > alondon wrote: > > > I would take a step back and try passing a PictureManager, if you've > implemented one, to the PictureController. I've never passed a DAO > directly to a controller. > > Sorry, > A > > > -----Original Message----- > From: Christian Decker [mailto:[EMAIL PROTECTED] > Sent: Tue 10/28/2008 8:42 PM > To: [email protected] > Subject: RE: [appfuse-user] Accessing DAOs in the controllers > > > Got it, but that didn't fix it :-( > > ---snip--- > public void setPictureDao(PictureDao pDao){ > pictureDao = pDao; > } > ---/snip--- > > alondon wrote: > > > PictureController needs a setPictureDao(PictureDao pictureDao) method. > > -A > > > -- > View this message in context: > http://www.nabble.com/Accessing-DAOs-in-the-controllers-tp20217953s2369p20219001.html > Sent from the AppFuse - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
