If your controller has too much logic you should really consider putting more of it in your model and view. Maybe I don't understand MVC, and you all can tell

If your controller has too much logic you should really consider putting more of it in your model and view. Maybe I don't understand MVC, and you all can tell me How Wrong I Am, but here's how I understand MVC at present: Your Model is a public API, a Service Gateway -- and it should do a couple of things in principle. The first is that it should be able to manage a list of subscribed view/controllers, and push updates out to them -- this was difficult with Web 2.0 but we're now moving to systems where this is considered normal. The second is that it should define a set of API commands which change that state and push out those subscriptions. That second bit is crucial, it's the difference between writing assembly and Python. If you have logic in your controller then it's probably because your model does not expose certain high-level concepts which your controller would use directly, so you're taking data from the model and building a higher-order model in your controller, before you operate on it. It helps me to remember that in Smalltalk the idea was to always have <view|controller> pairs. They were always the same object split in two; each view had its own controller and vice versa. The controller is supposed to be input-oriented and the view is supposed to be output-oriented; the model says "hey, X changed" and the view updates what X looks like; the user clicks on X and the controller sends a signal to the view to change some more, the user erases X and the controller sends this request to the model, which will update the view when the request is complete. Viewed this way it's really hard to see what the difference is supposed to be between MVC and MOVE. Clearly the messages in MVC are the Events in MOVE. Most of the controller logic has been pushed into the View, which should now handle input actions. Data cannot be dynamically pushed from the Model to the View because this is of course a Web 2.0 technology (pre-cometcasting, pre-websockets). The Operation sits in a grey area, implementing higher-order abstractions from the lower-order model. Maybe we could do better with a hybrid, because the idea of decoupling subscriptions from the public API might actually be a good idea, in line with the Clojure philosophy that things should be de-complected into their simplest representations. But if I understand MVC right, then I don't see why you've got all your business logic in your controller. Heck, the View is supposed to be client-side, why isn't your Controller client side? Or if it is, and you have all this business logic in it, why are you trusting the client to do your business logic? Your gripes with MVC don't make sense to me.