Mantenendo tutto loosely coupled ed estensibile: troppi strati, troppo piccolo ROI?

StackOverflow https://stackoverflow.com/questions/1251015

Domanda

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 è debolmente accoppiati. Non utilizzare direttamente un oggetto di dominio. Eseguire tutto attraverso un livello di servizio. Accesso ai dati attraverso un repository. Tutti i livelli sono perfettamente indipendenti.

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

Le spiegazioni che ho letto sono un po 'imbarazzante, come "in questo modo posso collegare un database diverso se ho bisogno di". Veramente? Io non credo che sia un problema comune che qualcuno chiede improvvisamente di passare da MSSQL a Oracle e adesso ti siedi lì e vi auguriamo avuto un milione di livelli che non tutti sanno l'uno dell'altro.

C'è una tendenza ad andare in mare con accoppiamento lasco, o sto solo leggendo i blog sbagliate? Come ci si sente su questo, e hai avuto casi in cui si è stati davvero contento dopo che avete fatto il lavoro supplementare in principio?

È stato utile?

Soluzione

E 'molto difficile progettare il diritto di business allineato il concepimento di un software. Cioe 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 si è sicuri di ciò che il software ha a che fare, e ci sarà probabilmente non grandi modifiche o aggiunge in futuro, un'applicazione super low accoppiamento di livello con un sacco di 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 sarà 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, il tempo spesa per la progettazione è totalmente proficuo, naturalmente.
Quindi, in sintesi, dirò che tutto dipende l'evoluzione del software in futuro e il potenziale di riutilizzo del codice per altre applicazioni.
Ma è una best practice per me fare non in modo sistematico l'architettura molto complessa.

Altri suggerimenti

Ovviamente, può essere esagerato, e si ha la necessità di sapere "dove fermarsi", aggiungendo strati.

La mia regola è, che se uno strato non ha bisogno di includere qualsiasi rilevanti e significative funzionalità / codice, io non ne ho bisogno. Detto questo, testabilità è una cosa importante, quindi se uno strato mi compra meglio testability, io aggiungerlo.

Niente in applicazioni di design arriva senza un prezzo. Qui il prezzo è aumentato complexibility. Hai sempre agli sguardi attraverso le opzioni prima di scegliere quello che si adatta alle vostre esigenze al meglio.

Con questo detto, credo che la tua domanda suona un po 'prevenuto. Nel mondo reale, non si potrebbe spesso di vedere un cliente che richiede un nuovo tipo di DB, ma si potrebbe spesso di vedere un nuovo cliente che vuole lo stesso tipo di accesso ai dati rispetto alla precedente, ma su un altro DB. Non è solo facilità di cambio, si tratta anche di code-riutilizzo.

Nel valutare queste cose di solito trovo utile a guardare attraverso la lente del principio DRY e guardando la duplicazione nel progetto.

Se stai usando un'architettura che è più complessa di quanto il progetto si tende a vedere un sacco di strati che fanno poco oltre avvolgono gli altri livelli e passano sulle chiamate. Questo si ripete da soli.

Se d'altra parte si sta utilizzando un'architettura sottile per un sistema complesso si potrebbe scoprire che la creazione di funzionalità in una parte del sistema non consente di riutilizzare le funzionalità che in un'altra parte, costringendo a scrivere un sacco di molto codice simile in tutto il luogo. Questo si ripete da soli.

Nella mia esperienza, se siete vigili per identificare la duplicazione e costantemente refactoring per rimuoverlo, la struttura si presenterà a voi. Diciamo per esempio che si sta partendo con un'architettura piuttosto semplice, ma rompere le cose fuori in metodi non appena hanno bisogno di essere riutilizzati, e rompendo i metodi fuori in classi non appena hanno bisogno per essere riutilizzati da altre classi. Poi si può finalmente capire che i tuoi 13 Helper / manager / classi handler che hai scritto per rimuovere la duplicazione in realtà cercare un po 'come stanno assumendo responsabilità che avrebbero potuto essere più chiaramente definita se fosse andato 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 un sacco di strati è essere molto chiaro con quali responsabilità i diversi strati dovrebbero avere. Ogni strato si aggiunge deve essere utile a voi nel ridurre la complessità delle operazioni nello strato sopra di esso e rendendo più facile tessere funzionalità insieme in modo elegante.

Prendere un progetto di esempio ipotetico. I test utilizzano vari database SQLite in-process per la velocità, il database di sviluppo sul computer di qualche sviluppatore è PostgreSQL, il database messa in scena è un unico Oracle installare, e il database di produzione è un altamente scalabile, molto costoso, e molto difficile da configurare Oracle cluster.

Come avrebbe mai tirare fuori senza separare lo strato di SQL dal livello di business?

Si tratta di una tendenza recente, e conduce meno esperti / architetti stanno cadendo preda di saltare sul carro.

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

Service Interface -> Servizio Attuazione -> Interfaccia delegato -> Attuazione Delegato -> DAO Interfaccia -> DAO Attuazione -.> Ibatis XML

Questo è stato (ed è!) Male nel nostro caso, in quanto la maggior parte del codice in qualsiasi metodo delegato implementazione è stata una sola linea; appena chiamato il DAO. Per ogni DAO, abbiamo avuto due classi in più e una configurazione di fagioli in più, e non siamo stati guadagnando nulla da questo.

Accettare la modifica, refactoring, e andare avanti. Utilizzare come molti strati che ci vuole a mettere a parte i concetti diversi ... e poi fermarsi. Se non c'è guadagno percepito a scrivere del codice, tranne che seguirà un modello, o rallentare e cercare di comprendere appieno il motivo per cui il modello ha fatto, o accettare che il modello è sbagliato per l'applicazione e ignorare quel po '.

Al momento sto lavorando ad un grande progetto SOA in cui è stato disaccoppiato ogni livello, e quasi ogni classe viene creata un'istanza tramite qualche fabbrica astratta. Ora stiamo cercando di scaricare alcune delle funzionalità esistenti in servizi in hosting a parte, ed è un vero e proprio incubo passare attraverso gli strati cercando di estrapolare i pezzi importanti perché c'è un infinito tasto destro del mouse> Vai a definizione ... ad inseguire giù quello che era solo 1 riga di codice al livello più esterno!

Non c'è niente di sbagliato con il disaccoppiamento di per sé, e certamente anche nel mio progetto ci sono molte aree in cui trovo utile dal punto di vista architettonico. Basta non avere portato via ... Siate pragmatici, e pesare i pro / contro in sede di esame delle aree si sta valutando di disaccoppiare.

Saluti

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top