I did a couple of very nice web-apps recently where the notion of “storing Perl objects” worked out extremely well. The objects are instantiated early in the process, and they then remain “persistent” from one page to the next. At the successful completion of a task, the data in the objects is transcribed back into the underlying database.

I find it to be definitely-true that real world apps often don't conform to “the CRUD scenario.” They aren't thinking in terms of the underlying database structures, whatever they might be, and furthermore they really don't want to be constrained to them or by them. And neither do you, as a programmer or a designer.

Furthermore, people like for apps to have a clear and definite “Pinnochio point...” a single well-defined moment when what they have begun to do finally “becomes a Real Boy.” (Until, and unless, that moment actually arrives, nothing permanent has happened, and they know it.) They want to be able to approach that point however they like, using the browser's “Back” button with reckless abandon and knowing that it will always work out right in the end.

Working with the idea of “storable, persistent objects” makes that sort of thing very easy to do. The temporal state of the transaction is represented in the stored object; the permanent state of the world is (eventually) reflected in the main database(s).