[sf-perl] ORM vs. DBI

Quinn Weaver quinn at pgexperts.com
Mon Feb 28 12:50:02 PST 2011


On Sun, Feb 27, 2011 at 1:01 PM, David Fetter <david at fetter.org> wrote:
> On Sun, Feb 27, 2011 at 12:10:31PM -0800, Quinn Weaver wrote:
>> I agree with the points made so far about the complementary (and
>> optional) nature of ORMs.
>
> I'd like to distinguish again between O-R mappers from SQL generators.
>
> Mappers are things that handle the translation between object-y things
> in the client code's world and the database's.  They're just generally
> good OO programming practice in the sense of encapsulation.
>
> SQL generators are a different beast entirely

So what you're saying is that one can write raw SQL, then allow the ORM to handle (only) the translation of the resultset to Perl objects? I like this approach; it gives you the best of both worlds. I'll make a note to mention it in the next iteration of my talk.

> I know it sounds like hair-splitting, but the ORMs with the most
> promise are precisely the ones which make this distinction.

If I understood you correctly above, Rose::DB::Object can do this. I believe DBIx::Class can as well, yes?

On occasions when I do use an ORM, I used to favor RDBO, but I now favor DBIC, because it is Moose-based (this allows for automated conversion of DBIC objects to JSON via introspection). They're both quite solid frameworks, though. DBIC is clearly the more popular. FWIW, RDBO also has the following property, cited by Fred Moyer in a later email about DBIC:

> Best of all, you can point it at your database and have it extract a full resultset
> library from it, to which you can add your own methods.

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)






More information about the SanFrancisco-pm mailing list