Archive - Originally posted on "The Horse's Mouth" - 2007-06-09 07:17:33 - Graham Ellis
Another technical term? Yes - this one is a formal name for how you convert a database into Objects - applicable to any OO language (Perl, Python, PHP, Java ...)
Let's reduce it to basics.
* SQL Tables become object classes
* Table rows each become individual objects
* Individual columns become attributes.
OK - perhaps you've been doing it for years .... I know I have, though not so formalised. It's nice to have a buzzword now to impress people with! But there's more to it than that.
By writing code to formalise the conversion of data held in databases to objects, you can add a layer of abstraction and move the need to write SQL code within your application our to a separate module - very possibly a module that's already been written and placed on the CPAN or in the Cheeseshop or PEAR.
In Perl, there have been a number of ORM modules placed on the CPAN; the current "flavour of the month" is DBIx::Class. A year or two back, it was Class::DBI, which you'll still find in use on some legacy applications. Both DBIx::Class and Class::DBI rely on Tim Bunce's DBI module internally, so they can be used with the same wide variety of databases that DBI/DBD supports.
When you map a table onto a class, you'll note that your code repeats the definition of the column names in the Perl code (or Perl configuration file if you're being really good). But the programming axiom is "don't repeat anything" and if you're feeling REALLY clever, you can use DBIx::Class::Schema::Loader to pick it up from the database - as the cost of a little inefficiency in that the extra database enquiry is made every time you run your Perl. And THAT inefficiency can be prevented with dump_to_dir.