Or you can expose the DAO as a property of the page, and do source="dao.findAll()" rather than source="findAll()".
On Thu, Nov 20, 2008 at 9:16 AM, Jonathan Barker <[EMAIL PROTECTED]> wrote: > > Ah, I had to jump in. > > I like using business services that keep data access code out of my pages. > That part feels good. > > Unfortunately, that often means that a findAll() in the DAO has a > corresponding findAll() in the service and that just feels silly. > > As a result, I tend to use services for "complicated" stuff that involves > multiple steps or DAO's, and do direct DAO calls from pages for the simpler > stuff. Sometimes that means that I'll be injecting services, and the DAO's > that the services use into my pages. That also feels silly. > > So then I consider the statement that DAO's have become an anti-pattern. It > makes sense when you consider the redundant findAll()'s that result from > separating data access and business services. On the other hand, it doesn't > feel good cluttering business services with HQL, SQL, or whatever. > > To really muck it up, I've got DAO's that extend a generic base DAO. That's > fine until the class hierarchy gets a few levels deep and now I'm writing > DAO's for Person, Customer, and Employee. > > If anyone figures out the "One True Way", let me know! In the meantime, > I'll settle for keeping Session out of my pages. > > Jonathan > > >> -----Original Message----- >> From: Chris Lewis [mailto:[EMAIL PROTECTED] >> Sent: Thursday, November 20, 2008 11:42 >> To: Tapestry users >> Subject: Re: Tapestry-IoC: binding service without code, just convention >> over configuration >> >> Thanks for the input Thiago. I'm curious about your reasoning for >> avoiding tapestry-hibernate. I use it for it's value encoder and primary >> key encoder auto wiring, and that's pretty much it. I avoid injecting >> Session into pages, and I assume that's the practice you specifically >> are avoiding in the name of separation of concern, is that right? >> >> I use the same kind of DAO pattern, and I manually wire up DAO >> implementations in bind() (which is where your idea might be interesting). >> >> I value quality architecture as well, but I'm still trying to understand >> what you achieve by slapping in the idea of an entity controller that, >> for what I can understand, is just a layer between your pages and your >> DAOs. Do share with me if you disagree, but I treat page classes as >> controllers for their views. In reality they're more like a box of >> controllers for the various components, but the point is the same. What >> value then do you gain from not interacting your DAOs directly, and why >> does that satisfy your architectural wants? >> >> Thanks again for sharing, I value such conversation :-). >> >> chris >> >> Thiago H. de Paula Figueiredo wrote: >> > Em Wed, 19 Nov 2008 17:37:48 -0300, Chris Lewis >> > <[EMAIL PROTECTED]> escreveu: >> > >> >> Hi Thiago, >> > >> > Hi, Chris! >> > >> >> Out of architectural curiosity, what do you use a UserController for in >> >> your example? >> > >> > I'm a strong supporter of n-tier architectures, so the view layer (in >> > this case, Tapestry) does no business rules nor does data storage >> > operations, just deals with the user actions*. Therefore, I have an >> > UserController (an interface) and UserControllerImpl, the class that >> > implements any business rules or processes (except persistence) >> > related to my User entity. >> > >> > To see one example of this, all the interfaces and classes cited in >> > this message are part of Ars Machina Project's Generic Authentication >> > package (http://www.arsmachina.com.br/project/genericauthentication). >> > You can browse its source here: >> > http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/generic- >> authentication/trunk. >> > >> > >> > For the persistence layer, I have DAOs and the Generic DAO and Generic >> > DAO-Hibernate packages >> (http://www.arsmachina.com.br/project/genericdao). >> > >> > UserController is a Controller (Generic Controller package, >> > http://www.arsmachina.com.br/project/genericcontroller), subinterface. >> > One of its methods is List<T> findAll(int firstResult, int maxResults, >> > SortCriterion... sortConstraints). If you thought of GridDataSource, >> > you're right. :) >> > >> > Tapestry CRUD (http://www.arsmachina.com.br/project/tapestrycrud), >> > another Ars Machina Project package, defines a BaseListPage<T, K> >> > abstract class (T = entity class, K = entity class primary key field >> > type). BaseListPage finds out what entity its is listing, then gets >> > its associated Controller instance. It is used to generating an object >> > listing using the Grid component. This is why I would like to provide >> > a default Controller instance if none is given: I wouldn't need to >> > create a trivial Controller implementation for that. ;) >> > >> > Have I satisfied your curiosity? :) If not, I can try to explain it in >> > a better way. ;) >> > >> > * That's why I don't use Tapestry-Hibernate: in my humble opinion, it >> > puts transaction control (a processing thing, it should be in the >> > business rules layer) in the wrong layer (view). >> > >> >> -- >> http://thegodcode.net >> >> >> --------------------------------------------------------------------- >> 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] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
