Where to put methods in a .NET Core MVC Web app?

Question

So I've gone through a few tutorials on writing .NET Core MVC Web apps. I think I've understood the flow from routing a request to the controller (with the EF-dbcontext injected into it) manipulating the dbSet model and onward to the view returning a response to the user.

I've been writing a little personal app to understand things. Now as this project grows the logic inside the controllers is growing and start to look ugly. How should this be handled?

I suppose I could just write functions next to the actions in the controller class, but that feels very wrong for some reason. Is this the Business Logic that people mention? Should I separate this into a Business Layer (in a separate project?), I often hear this mentioned along with a Data Access Layer, would this be needed as well?

I think these questions have been a little paralyzing and I would greatly appreciate some feedback and perhaps a link (or book) where I could read up on how this is done. :)

Answer 1

The business logic should only be in the Model because this logic is technology-agnostic (it doesn't matter you wrote an ASP.NET or a PHP app, the business logic stays the same) and the only part of an MVC app that could (and should) be technology-agnostic is the Model: the View, kinda obvious why it's bound to a technology, controllers are often bound to a view and their structure is often enforced by the technology.

The feeling you are experiencing in your controllers has a name: Fat Controller. It is commonly described as an anti-pattern (see here for its counterpart).

Next, to avoid your model classes to become god classes, I can advice you to have a look at the Clean Architecture which will help you to implement the MVC in a clean, reusable and testable way.

---

Here's how I see the different layers (note for experienced readers: I've willingly simplified to make it understandable for the OP):

View <==> Controller <==> Business model <==> Data access

Data access layer

Also known as DAL, its only purpose is to do a one-to-one with the database (or whatever storing system you use) and make the data available in an object-oriented application. IN C#, these classes often have the form of a POCO (containing only accessors) and have no logic (methods) inside. This layer is part of the Model (in the MVC sense).

Business model

Its purpose is to reflect the business reality. If you are developping a finance app, you will typically have all the computations in this layer (calculate interest, refunds, etc.). This layer should be framework-agnostic, so one shouldn't find any trace of SQl, XML or any storage possibility nor any call to Session, View, Console, etc. This layer is also part of the Model (in the MVC sense).

View

Its purpose is to declare what will be the outside boundary of your system. Generally it consists of an user interface but it could also be a web API, etc. This layer has no logic but only fires events based on outside triggers. As you probably guested, this correspond to the View (in the MVC sense).

Controller

Its sole purpose is to handle view events. It contains all the "routing" rules, i.e. knows that when event X is fired in the view, it should call method Y in the business logic to satisfy the user request. Again, as you probably guested, this correspond to the Controller (in the MVC sense).

I hope things are more clear now.