in reply to DBIx::Class, make me drool
I've only used DBIx::Class for one project, but I was completely sold on it once I was done. Unwriten SQL is the best SQL imo. Having every object map directly to a table row (whether a real table or a view) will definitely make your life easier. Doing common joins in a SQL client or in Perl is not very reusable in the network service sense. Java ORM clients will directly benefit from any views you create, but not from any SQL or Perl you write.
One annoyance I found using DBIx::Class, you end up with DBIx::Class objects, in a reserved DBIx::Class namespace. You don't really want to be doing anything other than DBIx::Class with those objects, so you end up with a spur on your namespace, where special objects exist that look nothing like any other objects. In my case SQL wasn't my only backing store, it was just a readonly copy of my Perforce metadata, along with additional business logic metadata. My SCM objects wanted to talk to Perforce for readwrite things, SQL for reporting and other things to avoid locking up Perforce. They could not simply isa DBIx::Class resultsets, they had to hasa resultsets, given the special DBIx::Class package structure.
In the end, the value DBIx::Class delivered in code agility and maintainability far exceeded the awkwardness of designing the namespace for ideal separation of concerns.