On Tue, 12 Jan 2010 11:32:31 -0200, matias.blasi <matias.bl...@gmail.com>
wrote:
You catched me perfectly.
I'm just researching if something like I described here exists.
I'm doubting about being exagerating, perhaps this is the problem. :)
:)
My only question now, is "what about tapestry-jpa?" isn't it an
abstraction for my scenario?
JPA is specification that defines how many things must be implemented.
Changing implementations shouldn't make any difference to your code that
uses JPA.
I don't consider it as an abstraction in this case because your DAO code
that uses JPA doesn't change when the JPA implementation is changed. So
what you need, if I'm got it right now, is already done by JPA being an
specification.
Even when changing JPA implementatinos, I don't think you're changing
technologies, as your code doesn't need to be changed.
It hasn't documentation yet, but Piero, correct me if I am wrong, if I
use the tapestry-jpa interfaces into my DAO implementation, I would be
de-coupled from the JPA implementation that I will be using at runtime,
right?
I was talking about JPA vs Hibernate vs Bigtable vs DB4O vs JDO vs. etc.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
