tags:

views:

211

answers:

3

I have an winforms application that was built using MVC. The controller is subscribing to all of the events from the view (button clicks, etc) and connects multiple views with the model.

The problem is that the controller is now about 3000 lines of (hard to unit test) code.

What is the best practice to avoid getting controllers to do everything and become so big?

A: 

Depends on the situation, but assuming you are not at a point where a new controller should be created there are several approaches.

Much depends on your setup. One common approach is to have a service layer or service agent which would do work for the controllers that is not specific. The use of interfaced helpers or even static ones should remove some of the repetition. 300 lines does not sound to bad at all assuming it is broken into testable methods.

I would be interested too to hear of other opinions other than the oft repeated mantra of creating more controllers. We use MVP and have experimented with sub controllers but this does rely on careful usage and is probably a bad idea.

It is common to have one controller per module in MVP, which would relate to a logical part of your application. There should be a few clear ones within your domain and a few that are maybe a bit more difficult to distinguish.

dove
I do not understand why sub controller should be more dangerous than 1 big contoller. You just split the code. It should be less dangerous because you can test it better.
Mister Dev
@Mister Dev you are correct but when I hear 'should' it also means things go wrong if someone doesn't know. It depends team, but it isn't uncommon for some folk to make sub controllers dangerous, i've seen multiple master controller constructors to suit the sub controllers. but this is a diff issue
dove
3000 is definitely a hint something could be improved, hard to put a number on it but i'd say anything over a 1000 starts to make it hard to navigate in one file. Think a new controller before then.
dove
+4  A: 

One obvious thing to point out might be that one controller does not have to be implemented as one class. The MVC design pattern simply states that M, V and C are separate components, but not that each must be one, and only one, class.

jalf
what are strategies for breaking up one large controller into smaller classes . .
ooo
The same strategy you'd use to break up any other code into smaller classes. Look at what it's doing, note what responsibilities it has, look at how these can be factored out. Then just draw a line around the resulting classes and say "that's my controller" :)
jalf
+3  A: 

Sub controller

Controller can be split in various sub-controller without broking the MVC pattern.

At 3k lines, it's for sure that the cohesion is broken somewhere. Try to group together same behavior and create new controller. This way, you will have a "main" controller that will invoke "sub" controller.

Method without sub:

For my own experience, I do not have 1 controller for the whole WinForm application. How I created it is that I have mutiple module that are loaded from the menu. When those module are loaded (Form->View) it comes with its own Controller. This way, I only have 1 controller for each module. Those controller aren't over 500 lines of code usually.

Daok