The only one I know of is
http://poop.sourceforge.net
I don't know how upto date it is.
Tim.
On Wed, Jul 31, 2002 at 09:28:07AM -0600, Jason Underdown wrote:
> Has anyone done a study which compares and contrasts the various
> Object-Relational mapping systems that Tim mentions below?
>
> By the way, I've also heard of another one called SPOPS:
> http://www.openinteract.org/download
>
> -----Original Message-----
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 31, 2002 5:33 AM
> To: NYIMI Jose (BMB); [EMAIL PROTECTED]
> Subject: Re: Hard-coding SQL in DBI violates OO encapuslation ?
>
>
> On Wed, Jul 31, 2002 at 03:13:49AM -0500, Stephen Clouse wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, Jul 31, 2002 at 09:25:15AM +0200, NYIMI Jose (BMB) wrote:
> > > Dear,
> > >
> > > A friend recommended me this white paper:
> > >
> > > http://www.ambysoft.com/persistenceLayer.html
> > >
> > > The Author suggests to implement what he called "Robust Persistence
> Layer"
> > > between "Business Classes" and "Storage mecanism" (ex Relational
> Database").
> > >
> > > Here an extrait from the white paper:
> > >
> > > "This approach to persistence effectively allows your database
> administrators
> > > (DBAs) to do what they do best, administer databases, without forcing
> them to
> > > worry about what their changes will do to existing applications. As long
> as
> > > they keep the data dictionary up-to-date they can make whatever changes
> they
> > > need to make to the persistence mechanism schema. Similarly, application
> > > programmers can refactor their objects without having to worry about
> updating
> > > the persistence mechanism schema because they can map the new versions
> of
> > > their classes to the existing schema. Naturally when new classes or
> attributes
> > > are added or removed to/from an application there will be a need for
> similar
> > > changes within the persistence mechanism schema."
> > >
> > >
> > > Is there in Perl's world a way to avoid hard coding SQL in DBI.
> > > I would like to have your opinion about this white paper.
> >
> > It's entirely correct in an OO context; however, you're confusing what the
> paper
> > describes with DBI :)
> >
> > DBI is simply the low-level database driver that handles the interface to
> the
> > database server. To fit it into the parlance of the aforementioned paper,
> DBI
> > is the PersistenceMechanism object.
> >
> > Obviously you have to write SQL at some point, because there's no other
> way to
> > talk to the database, and you need something like DBI to do the talking.
> The
> > point the paper gets at is to expose a data-centric object model to the
> > application, and let the object worry about building and executing the
> proper
> > SQL.
> >
> > Class::DBI is a good example of a Perl module that implements (most of)
> the rest
> > of that diagram, and probably a good place to start looking.
>
> Plus http://search-beta.cpan.org/author/SAMV/Class-Tangram/
> and http://search-beta.cpan.org/author/DROLSKY/Alzabo/
> and http://search-beta.cpan.org/author/AGUL/Persistence-Database-SQL/
> and http://search-beta.cpan.org/author/DWINTERS/Persistent-Base/
> and http://search-beta.cpan.org/author/DWINTERS/Persistent-DBI/
>
> "There's more than one way to do it! :)
>
> Tim.
>
