views:

279

answers:

2

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.

+3  A: 

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.

andyhammar
Working with thin controllers is definitely the way to go. One thing that I find very helpful is putting a service implementation between the controller and the repository. The controller basically just has a responsibility of coordinating what services to call, instead of worrying about the wiring of the data.
joseph.ferris
The model that the controller contains should contain only one type of model. If there are multiple models that can be used by the constructor then it is time to use an interface to determine common ground.
monksy
+1  A: 

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...

Frank V