Nice strategy :) Spring give you this out-of-the-box with its template
concept and general DAO exceptions.
On 4/6/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Both OpenEJB and Cayenne are currently in incubation and will support
> OpenJPA. Cayenne is an alternative to Hibernate (ORM).
>
> For what it's worth, my approach has been to create "DataStore"
> interfaces, each of which has database-layer independent methods for
> creating, deleting, updating, and searching for database entities. I
> believe this is a variation on the DAO approach.
>
> I then have a CayenneDataStore implementation that handles the
> database layer. It could easily be replaced by a HibernateDataStore
> or some other database layer.
>
> This keeps all of the database layer-specific code out of my app code
> and in the datastore class. Best of all, I can use code generation
> based on my Cayenne database model to build 80% of all the code in
> DataStore (using the gap generation pattern). Thus, all I need to
> implement myself are additional custom-purpose searching methods
> (findUserByLoginId, etc) and add them to my interface. These tend to
> be trivial to implement under Cayenne:
>
> public Individual findIndividualByFirstInitialAndLastName(
> String firstNameInitial, String lastName)
> {
> List andedExpressionList = new ArrayList();
>
> andedExpressionList.add(ExpressionFactory.matchExp(Individual.LAST_NAME_PROPERTY,
> lastName));
>
> andedExpressionList.add(ExpressionFactory.likeIgnoreCaseExp(Individual.FIRST_NAME_PROPERTY,
> firstNameInitial + "%"));
> return
> (Individual)findDataObjectByAndedExpressionList(andedExpressionList,
> com.gvea.admindb.entity.cayenne.Individual.class);
> }
>
> If for some reason I need to switch from Cayenne to Hibernate or to
> some in-house database layer, or to OpenJPA, then all I need to do is
> create a new DataStore implementation.
>
>
> On 4/6/06, Werner Punz <[EMAIL PROTECTED]> wrote:
> > Jonathan Harley schrieb:
> > > Werner Punz wrote:
> > >> Jonathan Harley schrieb:
> > >>> Indeed. Because JPA is such a limited standard (only covers
> > >>> relational datastores, for one thing),
> > >>
> > >> Actually that is not quite true, JPA is not really limited
> > >> to relational datastores
> > >
> > > Well, I suppose not but its query language is (yet another) dialect
> > > of SQL and it uses SQL and relational terminology throughout its
> > > annotations. It's clear what its designers had in mind.
> > >
> > Well object query sql derivates have been in existence for years now.
> > I even can remember that the ODMG 1.0 standard had such a thing.
> > This is no clear indication of trying to push the mapper towards
> > relational dbs only.
> >
> > The problem with all those is and in my opinion generally with OO
> > querying, there is up until now no clean we can cover all way to do the
> > queries. OQL and derivates only go a certain way, then you have to
> > follow different approaches. I never liked the we build our own query
> > tree approach some orm mappers follow. In the end I think 95-99%% OQL or
> > similar stuff, 5-1% different querying methods usually work best.
> >
> > The main difference the current approaches compared to Object Querying
> > languages only approaches of the past are that nowadays fallbacks are
> > allowed and expected.
> >
> > >>> JDO products as well as
> > >>> Hibernate and Toplink will offer many extensions to the JPA standard.
> > >>> Users will have a choice of using proprietary extensions (in the
> > >>> case of Hibernate and Toplink) that lock them in to one vendor, or
> > >>> standardised extensions (JDO) that give them a wide choice of vendor.
> > >>
> > >> Exactly, but the point is, there are no key issues why you have to lock
> > >> yourself into it.
> > >> In the future it probably will be, that it is best to code against jpa
> > >> and use the extensions wisely, if needed (and in most cases it wont be
> > >> needed)
> > >
> > > I disagree; I think it will be almost impossible not to use vendor
> > > extensions. Take lazy loading, for example. JDO 2.0 defines exactly
> > > which fields are available when an object is used while "detached"
> > > from the store, and defines the exception which is thrown if client
> > > code tries to access a different field. In Hibernate, whether access
> > > succeeds depends on whether the field was already loaded, but a lazy
> > > loading exception is thrown if not. In JPA, no particular behaviour
> > > is defined, the spec merely observes that it might be "unsafe". If
> > > you're using Hibernate JPA, no doubt you'll get the PROPRIETARY
> > > Hibernate lazy loading exception, but using another vendor you
> > > might just get null.
> > >
> > It is not perfect, but since most people proably will settle around
> > OpenJPA, Hibernate and the RI, I do not see this case exactly as a big
> > problem, because all three are opensource.
> > Anyway there are areas where a fix is needed, but that does not mean
> > that the JPA is a bad API, of all attempts to unify the ORM OODB layers
> > under a common standard this is one of the best so far.
> >
> > > Maybe this discussion is wandering a bit far away from JSF. The
> > > point I wanted to make is that if you like JSF because it's a
> > > standard which gives you the choice to change vendor (and that's
> > > certainly one of the things I use to persuade our clients that JSF
> > > is good) then you should also look at standards for other areas
> > > such as persistence. JPA is obviously worth a look, but right now
> > > it's unfinished and seems to me quite poorly thought out.
> > >
> > No standard is ever finished, JSF 1.0 was a huge construction site,
> > but with its third
> > incarnation (1.2) it is getting where it covers most grounds currently
> > needed.
> > And from what I have looked at, JPA is clearly a winner, all it needs is
> > some more flesh in some areas, but there always is the option for a JDO
> > and Hibernate fallback in 5% of the areas where needed and with OpenJPA
> > we soon will have an excellent JPA solution under the Apache umbrella
> > with one of the best ORM codebases in existence.
> >
> > (Basically from what I could gather, the BEA KODO JPA donation will
> > become Apache OpenJPA)
> >
> > As it seems all vendors rally behind JPA currently so the signs are
> > pretty clear, most people like it due to it being close to Hibernate,
> > and the vendors support it and there is a good set of already proven
> > codebases implementing it out there in the wild as OSS.
> >
> >
> >
> >
> >
>
--
Alexandre Poitras
Québec, Canada
