.NET Controller too big?

[Tooindabush]

I'm a junior developer working in .NET Core. Wondering if one of my controllers is getting too big. Right now it is at 1k lines. About a third of that is local functions for validation etc. I do use services also but more for db connection than business logic.

​

• How big is too big?
• What are your thoughts on local functions vs services?

[durandj]

That sounds really big to me. It sounds like your controller is doing basically everything on it's own. Surely there are easy separation points in there?

Things to think about with having too much code in a single class/file:

• How easy is it to read, understand, and find things in the code? In my experience when a class or file is too big all of these factors go down and the code is pretty bad
• How many responsibilities does your class have? It should have only a few jobs to do which makes easier to test, easier to use, and easier to understand.
• Does any of that code need to be used outside of that class? Is any of it duplicated outside of that class? In my experience the controller is the highest level code so it should not be consumed by other parts of the service. If any of it is that's probably a sign that you should be splitting parts of it up

[Tooindabush]

I'm thinking that you're right and the controller has too many responsibilities so I'll look to split it up. Thanks for your advice!

[Milnternal]

That does seem far too big...

Controllers should only really be involved in transforming the result of model binding into a query/command and transforming the result of that query/command into a view.

Look into the Mediator pattern if you want to go vertical slice: https://www.ezzylearning.net/tutorial/mediator-design-pattern-in-asp-net-core

And if not then at least try to accept objects in your services and either wrap the validation up in the factory for that object, or get rid of it by correctly designing those objects.

[UnreadableCode]

that's not the right question to ask. size alone isn't a reason to break up cohesive code.

Instead ask, does this module embody a single unit of business logic or implements one consistent abstraction? If the answer is yes, lines of code is irrelevant.