Costo opportunità del DI fai da te?

1

Java qui. Ho sempre utilizzato Spring DI (per progetti Spring) o Guice (per progetti non Spring) per l'iniezione di dipendenza e li ho sempre amati.

Recentemente ho preso un lavoro dove fanno il 100% "fai da te DI". Cioè, la classe main / driver di ogni progetto ha un metodo init() che crea per loro tutti gli oggetti / le fabbriche:

public class SomeApp {
    private DatabaseService databaseService;

    public static void main(String[] args) {
        SomeApp someApp = new SomeApp();
        someApp.run();
    }

    private void run() {
        init();

        // Now do some stuff (whatever SomeApp does).
    }

    private void init() {
        SomeAppConfig someAppConfig = readFromFileSystemSomehow();

        databaseService = new DatabaseServiceImpl(someAppConfig.getDatabaseInfo())
        // ...etc.
    }
}

Mi sento come se non ci fosse necessariamente sbagliato con questo DI DI , tuttavia mi sento come Guice e Spring DI esistere per un motivo, implementare le migliori pratiche di DI e gestire una varietà di situazioni migliori di quelle che qualsiasi soluzione di homegrown può gestire.

Vorrei provare a proporre Guice / Spring DI a questo team, ma prima voglio farlo in entrambi i casi:

  • Assicurati di avere ragioni concrete / concrete per spiegare perché questi progetti open source esistono e funzionano meglio di una soluzione fai-da-te; o
  • Forse modifica la mia visione del DI di DIY se è in effetti perfettamente soddisfacente e queste altre librerie (Guice / Spring DI / Weld / etc.) non sono realmente necessarie per le pratiche di DI appropriate

Quindi chiedo: Cosa si perde rinunciando a Guice / Spring DI / etc. e utilizzando una soluzione DI DI ? Qual è il costo opportunità?

    
posta smeeb 22.07.2016 - 12:34
fonte

2 risposte

5

Ci sono due motivi legittimi per il fai da te che mi viene in mente:

  1. Semplifica la tua vita. Una soluzione personalizzata può soddisfare le tue esigenze esattamente mentre provare a incorporare un approccio di terze parti può a volte essere più utile di quello che vale.
  2. Eliminazione / prevenzione delle dipendenze. Credo davvero che gli sviluppatori in generale non mettano abbastanza peso in questo. Ci sono dei costi per le dipendenze che non sono sempre inizialmente ovvi. Quando accoppi strettamente la tua applicazione a queste dipendenze, i costi potenziali sono molto più alti.

Sembra improbabile che 1 si applichi qui, ma 2 potrebbe. DI in Java ha iniziato a rotolare prima che ci fossero degli standard intorno a ciò con Spring che guidava il gruppo e Guice si è chiusa dietro di esso. Potresti pensare ora che non cambierai mai (mai e poi mai) da Spring ma non puoi saperlo. Alcuni dei progetti più costosi in cui sono stato coinvolto riguardavano l'estrazione delle dipendenze dalle dipendenze proprietarie. Ho visto le aziende passare attraverso il dolore di costruire una soluzione J2EE a causa della portabilità che fornisce e quindi utilizzare le funzionalità proprietarie del contenitore e sconfiggere completamente lo scopo.

Questo non significa che non dovresti seguirlo, ma questi sono i problemi che vorrei che ti rivolgessi se venissi da me con una proposta per presentare le dipendenze. Fai anche molta attenzione ai consigli di aziende che chiaramente beneficiano del fatto che sei dipendente dai loro prodotti. Hanno tutti gli incentivi per farti intrappolare irrimediabilmente nella loro rete di prodotti e spesso sottovaluteranno o elimineranno i rischi associati all'accoppiamento del tuo progetto alle loro soluzioni proprietarie.

Una nota a margine, Bob Lee è davvero strong e penso che abbia avuto tutte le giuste intenzioni quando ha creato Guice.

    
risposta data 22.07.2016 - 15:47
fonte
1

Mentre ci sono molti motivi per usare Spring (non ho mai lavorato con guizzi quindi non posso commentarlo) non sono sempre importanti per un dato progetto, ed è quindi una buona idea IMO almeno considerare DI fai da te per ogni nuovo progetto. Detto questo, finisco con più progetti Spring rispetto a quelli senza. I miei motivi più comuni per usare Spring sono:

  • demarcazione delle transazioni dichiarative. Questo mi fa risparmiare un bel po 'di codice standard nei luoghi in cui di solito non lo voglio.
  • dipendenze con scope (ad esempio in un'app Web con oggetti per sessione o per richiesta che vengono creati su richiesta) e riferimenti all'intervallo che funzionano (senza dover fare a meno di scrivere le mie proprie classi proxy)
  • spring mvc crea molti progetti tidiet rispetto alla mia solita alternativa di servlet che reindirizzano ai file jsp.
risposta data 22.07.2016 - 13:02
fonte

Leggi altre domande sui tag