I think the question is: at what point when designing from the bottom-up do you realize it was shorter to come at it from the top down? And at that point do you do a "52-pickup" and refactor, make the best of what you have, or continue working the way you were?
I used to do this, but haven't for a long time. I was really suprised when I got into this same mess a year or two ago writing a system that had multiple datasources and multiple valid object graphs.
Looking at this from the distance of a year or more, my mistake was in paradigms. I really should have went totally functional with the project instead of trying a classic OOP-tiering structure. Because my head was in the wrong place, I was like a guy with a square peg trying to get it into a round hole -- I just kept thinking I needed a bigger hammer.
Now I could have still kept an OO mentality and solved the problem -- no doubt about it. But that would have required more design up front than I gave it. So in this case lack of sufficient thinking up front combined with my head being in the wrong space caused the code base to be a lot more jumbled than it should have been.
So, my problem is that my solution is specific to my case and it's terribly complicated to explain to someone asking for advice on design patterns. So my question isn't actually how to write a good controller but what resources to recommend for intermediate-level coders asking for advice on the matter.