When you write your own MVC you'll come right back to the original patterns question. MVC is just the thing programmers interact with so they don't have to deal with inter-class interactions directly. But the MVC framework itself needs to manage those interactions somehow, using one pattern or the other.

Sure enough.

So your question is "How do I write good controllers?"

It's kinda hard for me to give you specific advice without a model and a set of behaviors to traverse. I guess "do good things" and "don't do stupid things" is about it. Singletons are not evil, but, like, gotos, I'd try to avoid them if at all possible.

In my experience, once you've matured the model enough for it to be code, you're automatically thinking in terms that leads to good design. Singletons pop out when you start with a small piece of the problem and try to bludgeon whatever you've got into a solution. These problems arise when you start to design from the bottom-up and use functional paradigms instead of OO paradigms. Nothing wrong with that, but for good code you should really pick one or the other and stick with it.

Looking back at my post I see my mistake. I understand OOP programming and class interactions very well, and as I mentioned have my own "pattern" that I'm using to great satisfaction; built, like you say, from the ground-up to serve that particular purpose. Getting there wasn't easy and certainly not reproducible - it was a mess.

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.

Not sure if I'm being helpful to you or not, but I'll reply again hoping I hit on something that you find useful.

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.