Embedding SQL right in your perl code is so 1995. All the cool kids these days use ORMs.
As annoying as the above couplet is, there is some truth to it. Sprinkling SQL throughout your code (especially long or complex sql inside of long or complex methods) can make an unreadable mess. It's also an embedding of an entirely different programming language as a string within your source. Unless you have a smarter editor than I'm used to using, this means that your SQL doesn't get syntax checked or highlighted - and your only recourse for debugging is to dig through your webserver logs.
SQL isn't a bad thing, though. On the contrary, it is an extremely expressive and terse language for extracting data from relational database systems, and is well supported by almost all of them. Most modern programming languages have bindings to some kind of SQL layer.
That's why we aren't afraid of SQL. It's good at what it does. For many of the things we do day to day in WebGUI, raw SQL is perfectly sufficient and doesn't make our code ugly. WebGUI::SQL abstracts away the more painful parts of the DBI, and we have one of these objects ready made for us with a $session->db call. Life is good.
As code gets more complex, though, it's sometimes appropriate to separate your codebase into Model-View classes. Here's where the ugliness starts to creep in - writing model classes by hand is tedious, repetetive, and (in my experience) almost always results in inconsistent and suboptimal APIs.
Since WebGUI 7.6, though, we have WebGUI::Crud. It's got a very WebGUI-ish syntax for defining simple table representations, very similar to what you're used to already in WebGUI::Asset's (and friends') definition method. It's a pretty thin layer over WebGUI::SQL, so all the power of raw SQL that you're used to is right there. This is the best practice for making consistent simple model classes in modern WebGUI code.
It's a bit of a stretch to call WebGUI::Crud an ORM, though. Because it's so lightweight, it's missing some convenience features and has no direct support for related sets of objects. While you often don't need those things in simple cases, it's nice to have options when you do need them. That's why we recommend DBIx::Class when you need a real, fully fledged ORM. It is widely used, has great community support and excellent documentation, and has all the power you'll need. Integration with the existing WebGUI APIs for database access is available via the Bazaar (see DBIx-Class-WebGUI).
No matter what level of database abstraction best fits your problem, we've got you covered. And you can stop telling those kids to get off your lawn - we've got ORMs in WebGUI, too. When they're appropriate.
