How to deal with really big controllers ...

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

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

What's the best practice to prevent controllers from doing everything and getting so big?


source to share

3 answers

The obvious point might be that one controller shouldn't be implemented as one class. The MVC design pattern simply states that M, V and C are separate components, but not all of them have to be one and only one class.



Sub controller

The controller can be split into multiple sub- controller without throwing the MVC pattern.

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

Method without sub:

For my own experience, I don't have 1 controller for the entire WinForm application. As I created this, I have several modules that are loaded from the menu. When this module is loaded (Form-> View) it comes with its own controller. This way I only have 1 controller for each module. Typically these controllers contain no more than 500 lines of code.



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

Much depends on your setup. One general approach is to have a service level or service agent that will work for controllers that are not specific. Using conjugated helpers or even static ones should remove some of the repetition. 300 lines doesn't sound bad assuming it's broken down into test methods.

I would also be interested to hear other opinions besides the often repeated mantra about creating more controllers. We are using MVP and have experimented with subcontrollers, but this depends on careful use and is probably bad ideas.

Typically, an MVP has one controller for each module, which will belong to the logical part of your application. There should be some clear ones in your domain, and some of them are perhaps a little more difficult to distinguish.



All Articles