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
In reply to Re^3: Why use an OO -> SQL mapper module?
by jethro
in thread Why use an OO -> SQL mapper module?
by MyMonkName
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |