Per imparare l'iniezione di dipendenza in un attuale progetto parallelo, sto scrivendo il mio contenitore per l'iniezione delle dipendenze.
Ma questo mi ha portato a chiedermi, a che punto vale la pena utilizzare un prodotto di terze parti rispetto a "roll my own"? Quale sarebbe il tipo di domande che vorresti per capirlo?
Per capire veramente uno strumento, mi piace creare la mia versione di detto strumento. Mi aiuta a capire cosa sta effettivamente facendo lo strumento e le parti difficili del problema che sta cercando di risolvere. Comprendere queste cose può aiutarti a prendere decisioni migliori su come utilizzare lo strumento.
Detto questo raramente raccomanderei di usare il roll-your-own sullo strumento in un vero progetto. Alcuni motivi per questo sono:
La decisione "acquista contro la build" si riduce a una serie di fattori. Riesci a mantenere lo strumento che stai acquistando (anche se è open-source)? C'è un supporto adeguato per questo, se si incontra un problema? Avete le risorse per costruirlo da soli e siete abbastanza intelligenti da generalizzarlo in modo che possa essere riutilizzato in una varietà di scenari? E così via.
Riguardo all'iniezione di dipendenza: i contenitori DI non sono necessari per la maggior parte delle applicazioni. A meno che la tua applicazione non sia una grande applicazione di tipo enterprise, non hai bisogno di un contenitore DI e, se ne hai bisogno, sono già disponibili alcuni contenitori che potrebbero servire allo scopo.
Le applicazioni più piccole traggono maggiormente vantaggio da una forma più semplice di DI, come l'iniezione delle dipendenze direttamente attraverso i metodi di costruzione dei tuoi oggetti. Utilizzerai un contenitore DI solo se dovessi fornire una posizione centrale per gestire le tue dipendenze, ad esempio in un file XML che li descrive.
Nel modo più vago, c'è una "regola del tre". Se ti ritrovi a fare la stessa cosa tre volte in un'applicazione software, puoi refactoring nel proprio strumento o metodo, o trovare uno strumento off-the-shelf che sostituisce queste tre cose con una cosa generalizzata. Sapere quando farlo è accompagnato dall'esperienza.
Pesare i vincoli di tempo rispetto a esigenze specifiche del progetto. Fa il
lo strumento fa esattamente tutto ciò di cui hai bisogno o ne vale la pena
% dix di ore richieste per completare la tua soluzione personalizzata?
Se si tratta di un progetto di gruppo: costo della licenza. C'è spazio sul budget del tuo dipartimento per permetterci di allocare risorse per lo sviluppo di una soluzione interna? I progetti interni richiedono molto tempo - e quindi costano un costo.
Leggi altre domande sui tag design-patterns reinventing-the-wheel third-party-libraries