continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: ContinuumStore refactoring
Date Thu, 28 Feb 2008 08:18:26 GMT
I'll create some examples asap.

Emmanuel

On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur <rahul.thakur.xdev@gmail.com>
wrote:

> Hi,
>
> Some code using a couple of Entities as examples would be nice :-)
>
> I still think the API would be verbose.
>
> Thanks,
> Rahul
>
>
> On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse
> <emmanuel.venisse@gmail.com> wrote:
> >
> >
> >
> >
> > On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur <
> rahul.thakur.xdev@gmail.com>
> > wrote:
> > >
> > >
> > > >> 2)   Criteria vs Named Queries: I am not convinced (yet) that Named
> > > >> queries are the way to go. I did some digging around, they are
> indeed
> > > >> best practices for JPA but I think the decision merits other
> > > >> consideration(s). I still believe the Criteria Queries will help us
> > > >> define a cleaner Store interface.
> > > >>
> > > >
> > > >
> > > > I'm always in favor of named queries.
> > > > An other point about them that I haven't explain in previous threads
> (I
> > > > think) is that with named queries, it is possible to modify queries
> > > > externally with xml files so if with a DB we have some performance
> > issues,
> > > > it will be possible to override queries by a modified JPQL query or
> a
> > native
> > > > query.
> > > >
> > >
> > > How do you see the refactored ContinuumStore interface using Named
> > > Queries? I suspect it will be just as verbose again.
> >
> > I don't want to see a new time a big class for the store part. it must
> be
> > splitted in few domains.
> > All named queries related to Project would be defined in the Project
> class,
> > all named queries related to ProjectGroup would be defined in the
> > ProjectGroup class...
> >
> > And we can add some more classes for particular results that aren't
> entities
> > objects (we won't have a lot)
> >
> > With this, all concerns are separated and linked to a specific entity.
> Easy
> > to code, easy to read, easy to understand. It's my opinion.
> >
> > >
> > > Sorry, still not convinced ;-)
> >
> > I hope you are now ;-)
> >
> > Emmanuel
> > >
> > >
> > > Rahul
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message