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.
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]
