First, in general, yes. I actually had decided that the next time I added a new top-level DB table and object class that I was going to make something like DbObject.pm and pull together all the generic SQL handling code in one place. I mean, how many cut and pastes of absorb_row do we really need? And combine it with Memcacheable and you should be able to create a new cached, DB-backed class with just a 'use base', some table and column name configuration, and a little bit of accessor programming.
That having been said... A lot of LJ/DW really does follow the Model part of MVC ok: LJ::Entry, LJ::User, and even LJ::Userpic are all Model implementations, if maybe not the cleanest examples of them. They're just all hand-coded Model implementations. So they're ugly, and have lots of duplicated code, and in some cases (keywords in particular) try to handle too much at once. But they are valid Models; you can, in a Controller, load up an Entry object, read it, and modify it without actually writing any new SQL. (edit: as pauamma says above.)
I miss Hibernate
That having been said... A lot of LJ/DW really does follow the Model part of MVC ok: LJ::Entry, LJ::User, and even LJ::Userpic are all Model implementations, if maybe not the cleanest examples of them. They're just all hand-coded Model implementations. So they're ugly, and have lots of duplicated code, and in some cases (keywords in particular) try to handle too much at once. But they are valid Models; you can, in a Controller, load up an Entry object, read it, and modify it without actually writing any new SQL. (edit: as