[sf-perl] ORM vs. DBI
friedman at highwire.stanford.edu
Mon Feb 28 13:06:34 PST 2011
DBIC can write your classes for you too.
Especially see `dbicdump`, which I used to great success. It'll dump the db to classes, even grabbing relations, foreign keys, and the like, and then just leave them there for you to modify to your heart's content.
-- Mike F
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu
On Feb 28, 2011, at 12:50 PM, Quinn Weaver wrote:
> 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.
> 1-888-743-9778 (my extension: 510)
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
More information about the SanFrancisco-pm