Trattare con una dipendenza spesso in corso che non è correlata alla classe

Question

Trattare con una dipendenza spesso in corso che non è correlata alla classe

#1 da (2 voti)
#2 da (0 voti)

1

Uso le classi di visualizzazione per i miei template. Queste classi di visualizzazione spesso richiedono alla classe di routing di ottenere URI da altre pagine. Potresti effettivamente dire che il routing dovrebbe essere disponibile per ogni classe di visualizzazione.

Quello che mi chiedo come ti occuperesti dell'iniezione di dipendenza. Iniettarlo attraverso il costruttore significherebbe che dovrai includerlo con ogni classe di visualizzazione in molti controller. Questo mi sembrerebbe sbagliato.

Lo includeresti anche con l'estensione della classe ma non credo che tutte le viste meritino una classe base per la sola libreria di routing e che possa rompere le regole SOLID che lo fai a causa di una dipendenza che non è direttamente correlata al classe di bambino.

La mia ultima opzione la inietterebbe tramite una variabile pubblica che la inietta in un posto solo poco prima del rendering del template.

Come avete risolto questo problema? Sto cercando un modo pulito e non ripetitivo.

dependency-injection design-patterns solid

posta RJD22 01.04.2014 - 12:19

fonte

2 risposte

0

Creerei un'interfaccia IRoutingAware con metodo SetRouting che consente al codice esterno di iniettare l'istanza di routing. Quindi ogni vista che implementa questa interfaccia dovrebbe avere un metodo chiamato dall'esterno prima che la vista sia resa. Questo sarebbe ancora meglio se tu avessi un posto unico dove le viste sono renderizzate, devi solo aggiungere due linee di codice. In C #, la funzione di impostazione potrebbe essere implementata in modo esplicito, il che renderebbe ovvio che il metodo non dovrebbe essere chiamato manualmente.

risposta data 01.04.2014 - 14:17

fonte

Leggi altre domande sui tag dependency-injection design-patterns solid

Qual è la differenza tra HaXe NME e OpenFL? Comprensione dei test delle unità per condizioni che cambiano dinamicamente

score 2 · Accepted Answer

Sembra che tu stia descrivendo una preoccupazione trasversale> .

Senza sapere cosa intendi esattamente per "modo pulito e non ripetitivo" nel contesto del tuo dominio problematico, non posso davvero suggerire soluzioni concrete. Framework che abilitano elementi simili a AOP come DynamicProxy e PostSharp potrebbe risolvere il tuo problema, ma ancora una volta, non posso davvero dire di sicuro senza sapere esattamente cosa stai cercando.

Quello che posso dire è che se hai applicato DI in modo corretto e coerente, la dipendenza di cui parli sarà intercambiabile e la classe che usa la dipendenza sarà facile da testare. Nella maggior parte degli scenari, questo rende il codice sufficientemente mantenibile. Quindi non mi preoccuperei troppo del fatto che una certa dipendenza si ripete in più classi perché questa è la programmazione OO per ya:)