MVC Design pattern smells?

Question

I must have implement MVC dozens of times in the context of various toolkits. I've noticed there are a few things that keep cropping up in the implementation which I'm not completely comfortable about. I was wondering if these are indeed things I should be looking to avoid. For instance

• The eternal Model instance - In an Single document application, There is only one instance of the Document class which always remains up to date. When a file is loaded, the content is cleared and read anew. The advantages of working like this are obvious but are there are hidden costs I'm not noticing?
• The monolithic Controller - The controller basically becomes the center of the system. all messages are routed through or by it. I remember hearing someone say that in principle, it should be possible to replace the controller with something else, a different controller. In my implementations this is usually impossible because the the controller knows everything.

MVC is such a high level concept. I'm wondering if there's some authoritative source on how exactly it should be implemented.

Answer 1

Interesting question.

My thoughts on this are:

• Model - hooking/unhooking

Can become a bit "greasy" if the document (or other domain object) is rich has has a lot of events. Everyone needs to hook themselves up on "CurrentDocumentChanged" and un-hook from the old object when a new one becomes the current one. Can leave unwanted references laying around.

• Controller

Yeah, the controller(s) can become large and almighty. What I especially think looks ugly is when the controller know too much about the model and controls application "flow". E.g. the controller has a BackgroundWorker that runs A in one model, then run B in another model etc.

Better pattern: Small views and small controllers. A page or window in the app can implement many views that each have their own controller. I.e. instead of having a DocumentPage with a DocumentController one can have an IAutoSaveTriggeringView, ISpellCheckTriggeringView, IFormatChangingView etc - and one controller for each.

Answer 2

I'm by no means an experts but I've experienced the exact same issue that you've described -- especially about the controller becoming monolithic. I'm glad that isn't just me.

I decided that, at least in theory, a potential solution to this is to refactor one's code in to more distinguished classes. In my theory, the use of the state pattern could help with a monolithic controller.

There are other patterns that might serve additional means but the idea is sound. Refactor the controller's contents in to smaller single-purpose-for-existing classes...