ORMs du jour?

[Sam Kington]

On 21 Oct 2013, at 17:19, Peter Corlett <abuse at cabal.org.uk> wrote:
> On 21 Oct 2013, at 15:33, Abigail <abigail at abigail.be> wrote:
> [...]
>> My recommendation for ORMs: don't.
>> 
>> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
> 
> I've only skimmed that article, but it seems to make the fairly common assumption that OO means Java-style OO, and because ORMs fit badly with his notion of OO and how it might be mapped to a relational model, all ORMs are bad.
> 
> Much of the blog post can be basically summed up by "the languages I use are too verbose, error-prone and inflexible that an ORM does not win me anything"[0]. Which is something I quite agree with.
> 
> Perl's is *not* like those languages, and DBIx::Class is not like those half-jobbed messes that Ted has apparently been burned by in the past. The people who built DBIx::Class have done a really excellent job of building something rather special.
> 
> 
> [0] Ted's LinkedIn page tells me he's basically a .NET programmer who has also touched Java and C++.


Seconded. Also, the article's sixth recommendation sounds awfully like how DBIx::Class works:

> Integration of relational concepts into frameworks. Developers simply accept that this problem is solvable, but only with a change of perspective. Instead of relying on language or library designers to solve this problem, developers take a different view of "objects" that is more relational in nature, building domain frameworks that are more directly built around relational constructs. For example, instead of creating a Person class that holds its instance data directly in fields inside the object, developers create a Person class that holds its instance data in a RowSet (Java) or DataSet (C#) instance, which can be assembled with other RowSets/DataSets into an easy-to-ship block of data for update against the database, or unpacked from the database into the individual objects.

At $WORK I was initially against adopting an ORM - mostly because we were adding Dancer and Moose to our code base already - but it's been invaluable. At its most basic it just gives you arbitrary classes based on your database tables, so you can use them as a glorified replacement for $dbh->fetchrow_hashref; but when you add the ability to automatically prefetch table contents, you can end up with very easy optimisation of your SQL queries without having to delve into the guts of the database.

Sam
-- 
Website: http://www.illuminated.co.uk/