So I just perused the documentation for Class::DBI ("a convenient abstraction layer to a database") and DBIx::Class ("allows abstract encapsulation of database operations") and I am struggling to see the point of using such a module.
I am not exactly a newbie with perl, although as somebody who learned it in the course of sys-admin/ops type work there was correspondingly less need for making everything into an object. That said, I understand perfectly well the reasoning behind OOP for software development, and a fortiori, modular code in general.
So I know there are dissenters from the OOP camp as a whole. That is not the hornets nest I want to kick at. I'm just wondering what benefit there is to replacing the conciseness of a SQL statement (which can be wrapped up into a method anyways, right?) with what looks like a mess of hashrefs that has to be over-ridden whenever there is something complicated to do anyways.
It seems this is touching on what Wikipedia calls the object-relational impedance mismatch but on my level of experience with these modules (which is admittedly nil) I'd hesitate to call it a "solution" as such. Am I not getting it? Anyone care to explain how this approach has made easy things easy and hard things possible, for them?
Thanks!In reply to Why use an OO -> SQL mapper module? by MyMonkName
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |