[OT]-ish Generic JPA Repository Frameworks

View: New views
3 Messages — Rating Filter:   Alert me  

[OT]-ish Generic JPA Repository Frameworks

by RogerV :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I've recently been come across references to generic DAO/Repository frameworks for JPA which attempt to reduce/standardize the code that you need to write to manage entities (e.g. http://grepo.codehaus.org/) Other approaches, such as taken by NetBeans, seem to be to auto-generate custom DAO Controller classes from the entity definitions .

As a newbie, I'd be interested in whether any of these generic DAO frameworks are any good, and if so which one(s) should I be looking at, or would I be better off with custom controller classes (auto-generated or otherwise)

Regards

Re: [OT]-ish Generic JPA Repository Frameworks

by tch :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Interesting, I looked at grepo but I really can't see adding yet
another abstraction layer on top of my code. We get by pretty well
with a standard DAO that's extended when needed.


./tch



On Tue, Oct 13, 2009 at 5:01 AM, RogerV <roger.varley@...> wrote:

>
> I've recently been come across references to generic DAO/Repository
> frameworks for JPA which attempt to reduce/standardize the code that you
> need to write to manage entities (e.g. http://grepo.codehaus.org/) Other
> approaches, such as taken by NetBeans, seem to be to auto-generate custom
> DAO Controller classes from the entity definitions .
>
> As a newbie, I'd be interested in whether any of these generic DAO
> frameworks are any good, and if so which one(s) should I be looking at, or
> would I be better off with custom controller classes (auto-generated or
> otherwise)
>
> Regards
> --
> View this message in context: http://www.nabble.com/-OT--ish-Generic-JPA-Repository-Frameworks-tp25869420p25869420.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Parent Message unknown Re: [OT]-ish Generic JPA Repository Frameworks

by Daniel Guggi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Regarding your question if any of these generic DAO frameworks are any good:

It would say yes. At least for grepo, as it helped us at Infonova. We
develop and
maintain relatively large applications for our customers with a
relative big development
team. We have strict rules for our DAO-Layer - besides standard CRUD operations
(like load/get/persist/update/flush/refresh etc.) we often need custom
methods to
execute custom queries (hql or jpql or native).

For such methods we do have conventions like
- methods starting with "load" always have to return a result object
or throw TooManyRows or
  NoDataFound (runtime) exceptions
- methods starting with "get" always have to return a result, null or
throw TooManyRows (runtime) exceptions
- methods starting with "find" always have to return a list or an empty list
- etc...

We had to extend most concrete DAOs from a DAOBase class (which
provided standard CRUD operations)
in order to provide the methods which execute custom queries. However
it turned out that those concrete DAOs
were often not implemented "correctly" (for instance load methods
returning null, not throwing exceptions etc...).
So we developed a framework (which resulted in grepo). Using the
framework we basically do not have to
develop concrete DAO classes anymore which saves time and furthermore
makes our DAO-Layer consistent
(e.g. a "load" method is always a "load" method etc.)

So grepo is not a framework (abstraction layer) which sits on top of
your code (because you should not have
to write custom code in most cases). Btw. grepo is non-invasive,
meaning that you can simply mix with
custom dao implementations or integrate in an existing DAO-Layer (this
is what we at Infonova actually did).

So all in all it depends on your requirements/problems/preferences
when you decide to use such a framework
or not.

Daniel
_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users