Perchè Disaccoppiare?

Questa è davvero una domanda interessante. A che proposito è necessario creare disaccoppiamento? E che cosa va fondamentalemente disaccoppiato?

In C# e più o meno in tutta la sfera della programmazione a oggetti il disaccoppiamento è molto forte. Anche se viene data molta libertà a chi scrive il codice per creare/costruire la propria logica.

Quando si parla di disaccoppiamento generalmente ci si riferisce al rapporto fra i dati e chi li gestisce, tipicamente fra il Business logic e il Data Layer.

Si intenda creare un livello che permetta la comunicazione fra dati e logica, ma che renda trasparente il passaggio.

Supponiamo il caso di dover scrivere un applicativo che ha le anagrafiche su Db, ma tutto il
resto è realizzato tramite XML.

Nei precedenti approcci alla programmazione avremmo dovuto ipoteticamente creare due
connessioni la prima sul Db la seconda ai file XML. Gestendo di volta in volta tutte le azioni
correlate.

Naturalmente con il rischio di mantenere un codice poco efficente.

Certo avremmo potuto scrivere due belle DLL, e fare in modo che fossero loro ad eseguire
tutti comandi necessari alla gestione dei dati, e già questo sarebbe stato un buon passo avanti.

Questo perchè disaccoppiare in senso lato vuol anche dire proteggere i propri dati, nascondendo
le connessioni, nascondendo i percorsi avremmo già ottenuto un buon livello di protezione, ma si tratta già di disaccoppiamento?

In c# è possibile strutture la propria soluzione in modo da creare i livelli proposti nel Mvc,
e possibile ( lo era anche con vb ... ) creare dei progetti correlati e naturalmente usarli.

Supponiamo qundi una soluzione tipo la seguente:

CrossFire
 prjDataLayer
 prjBusinessLogic
 prjPresentation-WA
 prjPresentation-WF

Banalmente una soluzione con 4 progetti.

Il primo si occupa esclusivamente dei Dati
Il secondo di applicare le logiche sulle richieste utente
Gli ultimi due sono possibili presentation (WA > windows Application, WF > web Forms)

Parrebbe un ottima soluzione e lo è se la fonte dati è unica.

CrossFire
 prjDataLayer
 prjDataLayer.SQLSEVER
 prjDateLayer.XML
 prjBusinessLogic
 prjPresentation-WA
 prjPresentation-WF

Già in questo modo si può intuire che c'e' (ben visibile) una diversificazione fra le fonti dati.

A tutti gli effetti il DataLayer dialogherà con il BusinessLogic ridirigendo le richieste a uno
dei due DataLayer specializzati.

Chiarmente in questo caso tutte le definizioni dei dati dovrebbero trovarsi in DataLayer.
in modo che BusinessLogic non sappia assolutamente dove questi realmente risiedano,
e di conseguenza anche i due presentation non avrebbero alcuna percezione di chi
fornisca loro i dati.

Si comprende quindi l'importanza del disaccoppiamento >> esso è uno strumento che consente di rendere INDIPENDENTI in senso stretto i dati da CHI LI GESTISCE e da CHI LI MOSTRA.

Certo va da se che maggiore è l'accuratezza nel creae disaccoppiamento e maggiore è lo sfrozo nello scrivere il codice.

Codice che tuttavia potrà ben essere riutilizzato.