La logica aziendale dovrebbe essere nel modello solo perché questa logica è indipendente dalla tecnologia (non importa che tu abbia scritto un ASP.NET o un'app PHP, la logica di business rimane la stessa) e l'unica parte di un MVC l'app che potrebbe (e dovrebbe) essere indipendente dalla tecnologia è il modello: la vista, un po 'ovvio perché è legata a una tecnologia, i controllori sono spesso legati a una vista e la loro struttura è spesso applicata dalla tecnologia.
La sensazione che stai provando nei tuoi controller ha un nome: Fat Controller. È comunemente descritto come un anti-pattern (vedi qui per la sua controparte).
Quindi, per evitare che le tue classi modello diventino delle classi di Dio, posso consigliarti di dare un'occhiata a Clean Architecture che ti aiuterà ad implementare l'MVC in modo pulito, riutilizzabile e testabile.
Ecco come vedo i diversi livelli (nota per i lettori esperti: l'ho volutamente semplificato per renderlo comprensibile per l'OP):
Visualizza < == > Controller < == > Modello di business < == > Accesso ai dati
Livello di accesso ai dati
Conosciuto anche come DAL, il suo unico scopo è fare un one-to-one con il database (o con qualsiasi sistema di archiviazione che si usa) e rendere i dati disponibili in un'applicazione orientata agli oggetti. IN C #, queste classi hanno spesso la forma di un POCO (contenente solo accessor) e non hanno logica (metodi) all'interno. Questo livello è parte del modello (nel senso MVC).
Modello di business
Il suo scopo è quello di riflettere la realtà aziendale. Se stai sviluppando un'app per le finanze, in genere avrai tutti i calcoli in questo livello (calcola interessi, rimborsi, ecc.). Questo strato dovrebbe essere indipendente dal framework, quindi non si dovrebbe trovare alcuna traccia di SQl, XML o qualsiasi possibilità di memorizzazione, né alcuna chiamata a Session, View, Console, ecc. Anche questo strato fa parte del Modello (nel senso MVC) .
Visualizza
Il suo scopo è dichiarare quale sarà il limite esterno del tuo sistema. Generalmente è costituito da un'interfaccia utente, ma potrebbe anche essere un'API Web, ecc. Questo livello non ha logica ma attiva solo eventi basati su trigger esterni. Come probabilmente guested, questo corrisponde alla View (in senso MVC).
Regolatore
Il suo unico scopo è gestire gli eventi di visualizzazione. Contiene tutte le regole di "routing", cioè sa che quando l'evento X viene attivato nella vista, deve chiamare il metodo Y nella business logic per soddisfare la richiesta dell'utente. Di nuovo, come probabilmente guested, questo corrisponde al Controller (nel senso MVC).
Spero che ora le cose siano più chiare.