Re: object-relational Perl programming: best practice or compromise?

If I'm writing programs that interface with a database then I'll almost always use Class::DBI. My reasons are largely pragmatic. Class::DBI has a large community of users and the support mailing list is full of clever people who are very happy to help out whenever I have problems.

Of course, it's not always true that the most popular option is necessarily the best, but when it comes to the selection of Perl modules I generally find that you don't go far wrong if you look at what the smart people at the heart of the community are using.

I don't know anyone who is using DBIx::Recordset or Ace, but I know lots of people who are using Class::DBI.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Comment on Re: object-relational Perl programming: best practice or compromise?

Replies are listed 'Best First'.
Re^2: object-relational Perl programming: best practice or compromise? by pg (Canon) on Oct 26, 2004 at 16:42 UTC
I also choose Class::DBI. I work for a Java shop, where c# is getting its way into this small peaceful world. It seems to me very normal to go Class:DBI. In my shop (or in the Java world), when we access database through Java, all data are wrapped in DCO (Data Container Object, and obviously they have bunch of getters and setters, for you to retrieve each column), and all access methods (select/update...) are wrapped in DAO (Data Access Object) object. Class::DBI has a very close idea behind, and makes great sense to me.	[reply]
Re^2: object-relational Perl programming: best practice or compromise? by geektron (Curate) on Oct 28, 2004 at 01:16 UTC
i have one large project at my place of employ that was written using DBIx::Recordset, and it is probably the biggest maintenance nightmare i have. it may not all be due to DBIx::Recordset, but every time something goes goofy, i do curse DBIx::Recordset ....	[reply]