I should also mention, I found it common and well-received to use this pattern for sustaining development on an enterprise app. Some logic has to be in the database anyway.
In my experience, keep the logic in / close to the data model and the application code becomes very clean and easy. If you have a crap data model, then lots of implicit rules start appearing at the application level, bugs start to appear and no one knows exactly what the application should be doing, as all the rules are tied up in some crappy crufty code.
Like Linus said, bed programmers worry about the code, good programmers worry about the data and its relationships (or something to that effect).
That experience is why I propose pushing as much business logic down into the data layer as possible as a matter of implementing a rite-of-passage code. For organizations, this puts a premium on db programmers, but it also protects their data from less-skilled programmers.
Like Linus said, bed programmers worry about the code, good programmers worry about the data and its relationships (or something to that effect).