One advantage immediately comes to (my) mind: You don't neccesarily need to know SQL
Hmmm. There's no reason not knowing SQL means you have to use an OO mapper. Furthermore, taking Class::DBI as an example, it only generates basic SQL for you. Anything a little bit non-trivial, you need to come up with yourself.
Class::DBI mentions two further advantages in its Introduction section
Eh, the "let's reinvent the wheel" section when it comes to triggers and such? You call that an advantage?
I find that Class::DBI doesn't abstract. Quite the opposite. By mapping tables to classes, it exposes the structure of your database to your application.
| [reply] |
There's no reason not knowing SQL means you have to use an OO mapper.
No, there is no reason to use OO if you want to abstract, but it is a possibility. And the original question was why should someone substitute SQL with OO.
Furthermore, taking Class::DBI as an example, it only generates basic SQL for you. Anything a little bit non-trivial, you need to come up with yourself.
If someone doesn't know SQL what are the chances that he will generate non-trivial SQL?
I find that Class::DBI doesn't abstract. Quite the opposite. By mapping tables to classes, it exposes the structure of your database to your application.
I don't have a problem with calling the abstraction a mapping instead. Note that the author himself says that Class::DBI "provides a *simple* database to object *mapping* layer" (emphasis added). The two advantages he mentions (higher oder functions usable without database having a say in it and abstraction of database implementation) still seem to hold even though they might not be implemented to everyones satisfaction
| [reply] |
If someone doesn't know SQL what are the chances that he will generate non-trivial SQL?
What are the chances someone not knowing SQL, and need to do something with SQL actually picks up a book, manual page, or a website and learns something? After all, people aren't born with knowledge how to use ORMs either. I'd say that for people who have already displayed the capability to learn how to use a Perl module, those chances are actually quite high.
Note that the author himself says that Class::DBI "provides a *simple* database to object *mapping* layer"
Have you actually used Class::DBI? It doesn't map databases to objects. It maps table rows to objects. And I wouldn't object to the notion that Class::DBI maps tables to classes.
abstraction of database implementation
But that isn't true. Not even for a small part. In its basis, it's "one table", "one class". It's painting the implementation of the database all over your name space. It actually takes a real effort to do worse of an abstraction job than Class::DBI does.
| [reply] |