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]
