Risposta breve
Il vantaggio principale del disaccoppiamento della logica applicativa da qualsiasi livello di presentazione / di interfaccia esterna è quello di consentire ai consumatori di variare in modo indipendente senza duplicare la logica. Pertanto, la necessità del disaccoppiamento dipende da quanti utenti avrà la tua applicazione.
Risposta lunga
Usando la nomenclatura Domain-Driven Design, la tua domanda potrebbe essere riformulata come " Perché includere un 'Application Layer' all'interno della tua architettura della soluzione? ".
L'Application Layer è inteso come interfaccia per il dominio e le esigenze infrastrutturali della tua applicazione, traducendo i messaggi di richiesta e risposta in interazioni con i componenti sottostanti. Con "tradurre" qui, intendiamo la conversazione di un messaggio logico in un formato standard in zero o più operazioni sui componenti sottostanti. Idealmente, una richiesta a un "Servizio di trasferimento fondi", che verifica l'input, indica al dominio di eseguire un trasferimento, persiste lo stato del dominio, registra l'operazione e notifica il mondo chiamando "Notifica servizio infrastruttura mondiale", potrebbe essere chiamato da un test a livello di componente o sottocutaneo, un'applicazione Web, un'applicazione console o essere esposto come servizio Web senza modifiche. Detto questo, la misura in cui una data soluzione beneficia di tale separazione delle strategie di preoccupazione dipende dal contesto.
Esistono, tuttavia, altri fattori che potrebbero portare a desiderare un certo grado di disaccoppiamento dall'interfaccia di consumo oltre alla necessità di fornire assistenza a più consumatori. Ad esempio, l'architettura ASP.Net MVC tende a indirizzare gli sviluppatori in operazioni di raggruppamento insieme per una determinata vista / pagina Web. Per le operazioni che vanno oltre le semplici operazioni CRUD su una singola radice aggregata, il design di Microsoft tende a condurre controllori privi di coesione rispetto allo stereotipo del ruolo dell'adattatore che devono servire.
Per spiegare meglio, mentre potresti avere un CustomerController le cui azioni riguardano esclusivamente i clienti e nient'altro che i clienti, ogni azione potrebbe richiedere a diversi collaboratori di raggiungere il loro obiettivo, non tutti sono necessari per ogni operazione. Una azione potrebbe dover salvare qualcosa in un database, un'altra potrebbe dover inviare una e-mail e un'altra potrebbe aver bisogno di memorizzare dati o inserire qualcosa in una coda di messaggi. Solo perché tutte queste azioni ruotano intorno a una singola radice aggregata, non significa che il ruolo che il controller è chiamato a svolgere (cioè l'adattatore) è coeso rispetto alle proprie responsabilità. Idealmente, un framework Web prenderebbe un messaggio HTTP in entrata e lo mapperebbe su un gestore di comandi all'interno del livello del servizio applicativo senza richiedere che Application Service Layer assuma una dipendenza dal framework Web .
La teoria dell'architettura e le motivazioni Feng Shui a parte, tutto si riduce alla necessità di riutilizzare la logica dell'applicazione che si sta per posizionare nella propria pagina Web / codice dietro / controller / gestore di comandi. In genere, il primo client che dovrebbe utilizzare la logica dell'applicazione è la specifica dell'eseguibile e la seconda è l'interfaccia di produzione. A seconda dell'approccio al test (nessuno, accettazione degli utenti, isolamento, ecc.) E della facilità con cui le dipendenze del framework che si prendono come parte dello sforzo di implementazione della logica dell'applicazione consentono di implementare le osservazioni della specifica, questo spesso determinerà il grado di disaccoppiamento che vuoi includere nella tua applicazione.