Em Thu, 20 Nov 2008 13:41:46 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
Thanks for the input Thiago.
All discussions are good discussions. :)
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?
Yes, but not the full matter.
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.
It isn't, and that's exactly where my point is. Most of the time a
controller method will just delegate to a corresponding DAO method, but
not always. My User controller save() method, for example, encrypts the
password before sending it to the DAO. This isn't a persistence issue, it
isn't an user interface one, it is a business rule issue, and I keep them
separate.
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?
This is a common confusion: there is the controller in the MVC pattern and
the controller in the 3-tier architecture, and both are different things.
A controller in MVC, in Tapestry, would be a page class. The View would be
the template. This MVC controller has only user interface code, not
business rules code. A controller in a 3-tier architecture has business
rules code and no user interface code. This way, for example, I can
implement a Swing interface to my applications just rewriting pure user
interface code. No business rules code is rewritten.
The advantage is complete separation of concerns: user interface in MVC,
business rules in controller classes and persistence in DAOs. This way, I
can change any tier implementation completely (as long as the tier
interfaces don't change) without affecting the other tiers.
Thanks again for sharing, I value such conversation :-).
So I do! :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
