Utilizza un livello di servizio con MVC

In 'SOLID' l''I' sta per Interface Segregation. L'idea di questo principio è di dividere le interfacce di grandi dimensioni in quelle più piccole, più modulari. Nel servizio MVC avrebbe normalmente un'interfaccia su cui il controllore farebbe affidamento. Non vuoi che i tuoi controllori sappiano dell'implementazione concreta di quel servizio. Pertanto, una serie di servizi con uno o due metodi è una buona cosa da avere.

I servizi restituiscono normalmente DTO in applicazioni di grandi dimensioni o modelli di dominio direttamente in applicazioni più piccole. DTO normalmente significa più lavoro, ma una migliore separazione delle preoccupazioni. Il flusso tipico è:

• Servizio chiamate controller
• Il servizio restituisce un oggetto (sia esso un DTO, un modello di dominio o qualcos'altro)
• Il controller associa il modello DTO / dominio a un modello di vista

La mappatura può essere eseguita manualmente, ma la maggior parte degli sviluppatori preferisce utilizzare il framework di mappatura automatica come Automapper perché non ci piace scrivere il codice del plumbing e possiamo essere piuttosto pigri: -)

link

link

Una delle molte discussioni sullo stackoverflow relative all'uso di DTO e modelli di dominio: link

I controllori devono contenere solo chiamate al modello (dove avviene la logica aziendale) e in base a quelle chiamate assegnare dati per la vista (oggetti di informazione o messaggi di errore), quindi i controllori saranno abbastanza piccoli anche per una pagina molto complessa, se il controller diventa ancora molto grande, dovresti pensare che forse quella pagina dovrebbe essere espansa in più pagine.

Ancora il modello può essere abbastanza grande ... la soluzione che ho trovato era avere una variabile all'interno del controller che indica quale modello caricare e per attività specifiche caricare il modello specifico.

Prova ad obbedire al modello model-view-controller pulito in questo modo:

• visualizza: visualizza i dati
• controller: raccoglie userinput, richiede il modello per i dati richiesti e lo rimanda alla vista
Modello
• : interagisce con il database ed esegue azioni logiche per preparare le informazioni

In MVC il modello non è solo un DTO o un insieme di manager / servizi che intende rappresentare i concetti che la tua applicazione sta modellando. Puoi pensare a questo come all'intero dominio o alla logica aziendale, inclusi stato e comportamenti. Ora dato che sappiamo che lo scopo del controller diventa un po 'più chiaro. Il suo compito è semplicemente quello di tradurre i comandi nel Modello e il risultato nelle viste. Questo viene solitamente eseguito sotto forma di ViewModels che sono diversi ma spesso confusi con il modello in MVC.

Se non si dispone di un modello ben definito, è possibile che si sia arrivati al punto in cui la maggior parte di tale logica risiede ora nei Controller stessi. A questo punto, per iniziare a ridurre le dimensioni dei controller, è possibile iniziare a reinserire questa logica in oggetti di gestione o di servizio. Questi servizi in genere restituiscono e operano su oggetti come DTO / Entity. Quindi il controller diventa lo strato di mappatura tra questi servizi e i modelli di vista. Per alcuni buoni consigli sulla mappatura, consulta questo articolo Gli amici non consentono agli amici di utilizzare AutoMapper .

Per quanto riguarda le tue domande, la prima dipende molto dalle tue applicazioni. Dovrai eseguire il refactoring lungo la strada che dovrebbe diventare più evidente una volta rimossa la logica dai controller. Per quanto riguarda i test, non vi è alcun problema a istanziare i modelli all'interno dei servizi, tuttavia se lo trovate difficile da testare è probabilmente solo un segno che è necessario suddividere il servizio in parti più piccole, ciascuna con una singola responsabilità.

Trovo i servizi veramente utili per eseguire la logica che potrebbe essere necessario eseguire da più di un controller o che non è abbastanza specifico per far parte del controller, oltre al fatto che impedisce ai controller di diventare troppo grandi e difficili da leggere ...

Personalmente non sono d'accordo con 'aaa' quando dice che "modello (laddove la logica di bussiness accade)" visto che questo è il motivo per cui possiedi controller, a mio parere i modelli devono essere semplici dati astratti in modo che il controller possa svolgere il compito richiesto ; di nuovo i servizi non dovrebbero essere coinvolti nell'attività di astrazione dei dati ...

Sto solo dicendo ....