Mantenere tutto liberamente accoppiato ed estendibile: troppi strati, ROI troppo piccolo?

Question

I (ora più che mai) vedere gli sviluppatori a scrivere enormi quantità di strati come ad esempio:

implementation PresentationLayer -> 
    interface IMyDTO -> 
     implementation MyDTO -> 
      interface IMyService -> 
       implementation MyService -> 
        interface IMyDomainRepository -> 
         implementation MyDomainRepository -> 
          interface IMyDomainObject -> 
           implementation MyDomainObject -> 
            interface IMyIndependentStorageLayer -> 
             implementation MyMSSQLStorageLayer 

Guardando attraverso C# blog, questo sembra la cosa migliore dopo il pane a fette. Fondamentalmente, tutto è liberamente accoppiato. Non utilizzare direttamente un oggetto dominio. Esegui tutto attraverso un livello di servizio. Accedi ai dati attraverso un repository. Tutti gli strati sono perfettamente indipendenti.

Non fraintendetemi, mi piace l'idea, ma non è il trade-off nel tempo enorme, soprattutto su un progetto più ampio? Il ROI nella manutenzione è abbastanza grande da giustificare questo?

Le spiegazioni che ho letto sono piuttosto scomode, come "in questo modo posso allegare un database diverso se necessario". Veramente? Non penso che sia un problema comune che qualcuno chieda all'improvviso di passare da MSSQL a Oracle e ora ci si siede lì e si desidera avere un milione di layer che non si conoscono l'uno dell'altro.

C'è una tendenza a esagerare con un accoppiamento lento o sto solo leggendo i blog sbagliati? Come ti senti al riguardo e hai avuto casi in cui sei stato davvero contento di aver fatto il lavoro extra all'inizio?

Answer 1

È molto difficile progettare il corretto concetto di business allineato per un software. Intendo con un ROI accettabile.

Tuttavia, per me, il numero di strati o il livello di bassa accoppiamento di una concezione software è a seconda del contesto in cui verrà utilizzato il software!

Se sei sicuro di ciò che il software deve fare e probabilmente non ci saranno grandi modifiche o aggiunte in futuro, un'applicazione di accoppiamento a livello molto basso con molti strati non è la soluzione. Perché rende l'architettura troppo complesso, senza alcuna ragione e il tempo investito per l'architettura non è redditizio ...
D'altra parte, se si sa che l'applicazione dovrà essere personalizzato per ogni cliente e verrà certamente modificare in profondità, così il tempo trascorso ad un'architettura accoppiamento basso livello è una buona idea ...
accoppiamento a basso livello può essere intelligente quando si vuole riutilizzare parte del codice per altre applicazioni. In questo caso, ovviamente, la spesa in termini di tempo per il design è totalmente redditizia.
Quindi, in sintesi, dirò che tutto dipende dall'evoluzione del software in futuro e dal potenziale di riutilizzo del codice per altre applicazioni.
Ma è una buona pratica per me non fare un'architettura sistematicamente molto complessa.

Answer 2

Ovviamente, può essere esagerato e occorre conoscere "dove fermarsi" l'aggiunta di livelli.

La mia regola generale è che se uno strato non ha bisogno di includere alcuna funzionalità/codice significativo, non ne ho bisogno. Detto questo, la testabilità è una cosa significativa, quindi se un livello mi offre una migliore testabilità, lo aggiungerò.

Answer 3

Niente nel design di un'applicazione viene fornito senza un prezzo. Qui il prezzo è maggiore complessità. È SEMPRE necessario esaminare le opzioni prima di scegliere quello più adatto alle proprie esigenze.

Con ciò detto, penso che la tua domanda sia un po 'parziale. Nel mondo reale, potresti non vedere spesso un cliente che richiede un nuovo tipo di DB, ma potresti spesso vedere un nuovo cliente che desidera lo stesso tipo di accesso ai dati rispetto al precedente, ma su un altro DB. Non si tratta solo di facilità di modifica, ma anche di riutilizzo del codice.

Answer 4

Nella valutazione di queste cose di solito trovo utile guardarlo attraverso l'obiettivo del principio DRY e osservare la duplicazione nel progetto.

Se stai utilizzando un'architettura più complessa del tuo progetto, tenderai a vedere molti strati che fanno poco oltre a sovrapporre altri livelli e passare le chiamate. Questo si sta ripetendo.

Se invece si utilizza un'architettura sottile per un sistema complesso, è possibile che la creazione di funzionalità in una parte del sistema non consenta di riutilizzare tale funzionalità in un'altra parte, costringendovi a scrivere molto codice molto simile dappertutto. Questo si sta ripetendo.

Nella mia esperienza, se si è vigili nell'individuare la duplicazione e costantemente refactoring per rimuoverlo, la struttura si presenterà a voi. Supponiamo ad esempio che tu stia iniziando con un'architettura piuttosto basilare, ma rompendo le cose con i metodi non appena devono essere riutilizzati e suddividendo i metodi in classi non appena devono essere riutilizzati da altre classi. Quindi potresti finalmente rendersi conto che le 13 classi di Helper/Manager/Handler che hai scritto per rimuovere la duplicazione sembrano davvero un po 'come se assumessero responsabilità che avrebbero potuto essere definite più chiaramente se fossero entrate in un livello di servizio.

Può essere difficile sapere quando ne vale la pena, ma penso che la chiave del successo nella costruzione di un sistema con molti livelli sia molto chiara con quali responsabilità dovrebbero avere i diversi livelli. Qualsiasi livello aggiunto deve essere utile per ridurre la complessità delle operazioni nel livello sopra di esso e rendere più semplice intrecciare le funzionalità in modo elegante.

Answer 5

Prendere un ipotetico progetto di esempio. I test utilizzano vari database SQLite in-process per la velocità, il database di sviluppo sul computer di alcuni sviluppatori è PostgreSQL, il database di staging è una singola installazione Oracle e il database di produzione è un Oracle estremamente scalabile, molto costoso e molto difficile da configurare grappolo.

Come si potrebbe mai fare a meno di questo senza separare il livello SQL dal livello aziendale?

Answer 6

È una tendenza recente, e lead/architects meno esperti stanno cadendo preda del salto sul carro.

Nel progetto sono su, l'accesso ai dati è andato:

Service Interface -> Servizio Attuazione -> Interfaccia delegato -> delegare la realizzazione -> DAO Interfaccia -> DAO Attuazione -> Ibatis XML.

Questo era (ed è!) Cattivo nel nostro caso, perché il maggior numero di codice in qualsiasi metodo di implementazione dei delegati era una singola riga; ha appena chiamato il DAO. Per ogni DAO, avevamo due classi extra e una configurazione extra di bean, e da questo non ottenevamo nulla.

Accettare la modifica, il rifattore e andare avanti. Usa tutti i livelli necessari per separare concetti diversi ... e poi fermati. Se non vi è alcun guadagno percepito nella scrittura di un codice, tranne che seguirà un modello, rallentare e cercare di comprendere appieno perché il modello ha fatto ciò, o accettare che il modello sia sbagliato per l'applicazione e ignorare quel bit.

Answer 7

Attualmente sto lavorando a un grande progetto SOA in cui ogni livello è stato disaccoppiato, e quasi tutte le classi sono istanziate tramite una fabbrica astratta. Ora stiamo cercando di scaricare alcune delle funzionalità esistenti in servizi hosted separatamente, ed è un vero incubo attraversare gli strati cercando di estrapolare i bit importanti perché c'è un clic infinito> Vai alla definizione ...per inseguire ciò che era solo una riga di codice nello strato più esterno!

Non c'è niente di sbagliato nel disaccoppiamento di per sé, e sicuramente anche nel mio progetto ci sono molte aree in cui trovo utile da un punto di vista architettonico. Basta non lasciarsi trasportare ... sii pragmatico e soppesa i pro/contro quando esamini le aree che stai considerando di disaccoppiare.

Cheers