The Model you're talking about is an ORM -- Object Relational Mapping. Taking an RDBMS (relational database) and mapping it to an OO system. The "way" to do that in Perl is with DBIx::Class (http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class.pm), by mst.
I've used this system before in a Catalyst application I built and when I was at Six Apart they used it for things. It certainly has a lot of nice functionality, and you can make it do some interesting things.
I never found it particularly useful, though. It's easier for me to see the raw SQL and know what it's doing.
Now, one thing I did always want to do was to create objects for the various classes of data (models basically) but not use an ORM. The system would not automatically scan the tables for keys and such. I would just define classes that had all of the SQL self-contained. Then the rest of the application would be 100% free of SQL, which would be a boon if we ever wanted to change backends or whatnot.
Eh. Not a useful comment, I suppose. I have vague low-level distrust and dislike of ORMs. I think it's hard to use them well and they're mostly a crutch.
no subject
I've used this system before in a Catalyst application I built and when I was at Six Apart they used it for things. It certainly has a lot of nice functionality, and you can make it do some interesting things.
I never found it particularly useful, though. It's easier for me to see the raw SQL and know what it's doing.
Now, one thing I did always want to do was to create objects for the various classes of data (models basically) but not use an ORM. The system would not automatically scan the tables for keys and such. I would just define classes that had all of the SQL self-contained. Then the rest of the application would be 100% free of SQL, which would be a boon if we ever wanted to change backends or whatnot.
Eh. Not a useful comment, I suppose. I have vague low-level distrust and dislike of ORMs. I think it's hard to use them well and they're mostly a crutch.