Right, this is actually what we are doing.
We have the queries defined in the entity via @NamedQuery (since we
just JPA). Our generic DAO just allows me to specify the name of the
query, set the parameters and get the results back.
Auto-binding is actually what I was looking for, I just have entities
defined in various modules and wanted to see if I could centralize
auto-binding the DAOs in one place.
Cheers,
Miguel
On 31.08.2012 02:10, Markus Grell wrote:
Greetings!
I'm no expert at all for this topic but I can't see your problem with
generic DAOs. I wrote a couple of typical database apps and they all
use
generic DAOs. Stuff that is unique to an entity is handled by named
queries defined in the entities.
Works great and saves a lot of code to write.
Markus
Why do you ever need such a generic DAOs at all?
For example, here's how my DAOs look like:
http://imgbin.org/images/9339.png
There's not so much common between them and I'm sure you will have
similar structure.
You may also have some class hierarchy for you DAOs (say all your
DAOs
will inherit CRUD methods from GenericDAO), but this doesn't relate
to
Tapestry
at all.
To let Tapestry create *instances* of your DAOs for you (with
dependency
injection and all cool stuff) you should declare your DAOs in your
AppModule like this:
public static void bind(ServiceBinder binder) throws
ClassNotFoundException
{
binder.bind(UserDAO.class, UserDAOImpl.class); // etc.
}
Or you can try to auto-bind them like described here:
http://killertilapia.blogspot.com/2012/08/autobind-all-tapestry5-services
.html
On Fri, Aug 31, 2012 at 2:15 AM, Miguel O. Carvajal <
tapes...@carvajalonline.com> wrote:
Hey all,
I am taking a look again at how we have implemented a generic DAO
in
our Tapestry application, since our currently implementation is a
bit
hackish.
I was looking at the great article over at
http://tawus.wordpress.com/**
2011/05/28/tapestry-magic-13-**generic-data-access-objects/<http://tawus
.wordpress.com/2011/05/28/tapestry-magic-13-generic-data-access-objects
/>
And while I do see it as an option, it seems a bit verbose for
doing
something that maybe I can do with less code in Tapestry.
I saw in the issue 2550 (https://issues.apache.org/**
jira/browse/TAPESTRY-2550<https://issues.apache.org/jira/browse/TAPESTRY
-2550>)
that ServiceBuilder was created exactly for this purpose, but since
I
have no way of determining the generic type (or other way of
determining
what Hibernate/JPA entity I am working with) within the
ServiceBuilder
implementation. I just don't see how this can be done with
ServiceBuilder.
Is there something obvious I am missing or is the article I
mentioned
above the only way it can be done?
Thanks,
Miguel
------------------------------**------------------------------**-------
--
To unsubscribe, e-mail:
users-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apac
he.org> For additional commands, e-mail:
users-h...@tapestry.apache.org
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
