Come riutilizzare le parti della dipendenza della composizione di iniezione

Question

Come riutilizzare le parti della dipendenza della composizione di iniezione

#1 da (3 voti)
#2 da (2 voti)

-1

Attualmente sto lavorando su una grande applicazione (un centinaio di librerie, diverse migliaia di classi) con diversi punti di ingresso (sito Web MVC, servizi web, alcuni agenti in background, scheduler di lavoro ...).

La maggior parte di questi punti di ingresso utilizza una parte non trascurabile dei servizi di base (direi almeno il 50% almeno).

So da fonti credibili che le radici di composizione non devono essere riutilizzate.

Per quanto io sia d'accordo con l'intera idea, nel mio caso particolare, ogni radice di composizione ha molto (e intendo dire) di codice duplicato, e sembra una cosa brutta, come so per certo che la maggior parte le interfacce / i collegamenti impl resteranno gli stessi indipendentemente dal punto di ingresso per almeno un po 'di tempo.

Potrei decidere di non preoccuparmi, ma questa situazione significa che ogni volta che voglio aggiungere una nuova associazione per una nuova classe, devo cambiare forse nove diverse radici di composizione.

Alla fine, ho fornito parti di radici di composizione preconfigurate direttamente nei progetti che gestiscono le implementazioni (almeno questo non cambia nulla quando si tratta di accoppiamento lento), quindi devo solo chiamarle dalle radici della composizione globale quando bisogno di loro, ma questo non sembra un approccio corretto.

Qualcuno ha un'alternativa migliore?

dependency-injection

posta xlecoustillier 12.10.2017 - 21:33

fonte

2 risposte

2

La regola generale è, cerca di evitare di riutilizzare il codice di composizione. Perché andrà tutto bene e dandy fino a quando non incontrerai un caso eccezionale per un grafico specifico che è solo un piccolo diverso dagli altri e ora il tuo codice di composizione sta per diventare pieno di ifs, ands e buts.

Tuttavia, questo non vuol dire che questa regola non possa essere infranta quando ha senso e se ha senso per il tuo scenario non mi preoccuperei troppo della regola; ci sono un paio di cose che puoi fare per alleviare il dolore.

Utilizza il cablaggio basato su convenzione il più possibile

La maggior parte delle librerie IoC che vale la pena utilizzare avrà una scansione di assembly basata convenzionale che può collegare automaticamente il IFoo all'implementazione Foo automaticamente. Più ci si può appoggiare a questo, meno codice si deve mantenere.

Se ad esempio disponi di centinaia di interfacce con una sola implementazione, puoi sostituirla con una singola riga di scansione basata sulla convenzione.

Utilizza i registri il più possibile

Anche in questo caso tutte le librerie IoC avranno un concetto di registro o somesuch che consente di raggruppare i relativi cablaggi; tipicamente questi sono sotto forma di una classe base specializzata ( Registry è la StructureMap, per esempio.)

Una cosa bella di questo è che può essere parametrizzato così anche se hai casi particolari (ad esempio tutti i moduli collegano IFoo a Foo eccetto questo che usa SpecialFoo) puoi incapsulare quel processo decisionale nel registro; quindi "riutilizzare" il codice di composizione direttamente diventa meno preoccupante perché quello che stai facendo è aggiungere un set di classi del Registro di sistema al contenitore IoC per modulo. Questo finisce per essere molto meno codice da gestire tutto in una volta e suona in modo simile a quello che stai facendo attualmente, ma non hai menzionato se ti stavi appoggiando direttamente alle strutture del registro di IoC o semplicemente facendo rotolare a mano questo.

risposta data 12.10.2017 - 23:16

fonte

Leggi altre domande sui tag dependency-injection

Come faccio a consentire ad altri sviluppatori di integrare i moduli nel mio generatore di contenuti? Esiste un termine per un'entità che rappresenta un'altra entità nota mancante?

score 3 · Accepted Answer

Ok Ecco la mia versione. Non è "una singola applicazione con più punti di ingresso" le sue molteplici applicazioni che condividono il codice.

Vorrei provare a ridurre la quantità di codice che le applicazioni stanno condividendo. per esempio. Invece di avere un servizio Web e un processore di lavoro che eseguono entrambi la stessa attività in modi diversi, chiedi al responsabile del lavoro di chiamare il webservice e di estrarre tutto il codice che non ha più bisogno.

Se una funzione utilizza solo il 50% della composizione radice, quindi la divide e rimuove il 50% non utilizzato. Metti questa funzione nel proprio microservizio e fai in modo che tutto il resto che usa quel 50% lo chiami e ritocchi di conseguenza il proprio codice.

In alternativa, se non ti piace l'approccio microservice, vai dall'altra parte e hai un singolo monolite webapi che fa tutto tranne che è l'unica cosa che ha la radice composizione complessa. Avere tutto il resto come un thin client che lo chiama.