Iniezione delle dipendenze di ViewModel con parametro non gestito

Question

Iniezione delle dipendenze di ViewModel con parametro non gestito

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

2

Ho un PersonEditViewModel che ha bisogno di altri due oggetti, personId e PersonRepository . PersonRepository è ottenuto da un localizzatore di servizio:

private final int personId;
public PersonEditViewModel(int id) {
    this.personId = id;
    this.personRepository = ServiceLocator.get(PersonRepository.class);
}

Ma vorrei usare l'iniezione di dipendenza (DI, IoC) per ottenere PersonRepository , preferibilmente via costruttore:

public PersonEditViewModel(PersonRepository pr) {
    this.personRepository = pr;
}

Il mio problema è, come posso passare personId al costruttore nel pattern DI? Devo fare un setter per id - allora DI cambia la logica del PersonEditViewModel (il campo personId non può essere definitivo)? E 'insufficienza del pattern DI che non posso passare oggetti dati al costruttore, o devo cambiare idea e progettare il mio ViewModels in un altro modo, probabilmente usare altri pattern per passare oggetti dati a loro?

Modifica: ha modificato la mia domanda utilizzando personId e PersonRepository per essere più vicini alle situazioni comuni.

dependency-injection java service-locator

posta xmedeko 16.06.2015 - 20:48

fonte

2 risposte

Leggi altre domande sui tag dependency-injection java service-locator

Sviluppo iOS Bluetooth: mimando il profilo SPP Programmazione su più back-end

score 1 · Answer 1

Oltre a quello che ha detto Ian nella sua risposta, il seguente dovrebbe darti una prospettiva diversa su questa cosa.

Cerco di rispondere alle seguenti due domande su una dipendenza prima di decidere sul meccanismo per passare l'oggetto dipendenza in giro.

Sto per usare la dipendenza?
Chi è responsabile per l'istanziazione della dipendenza?

La risposta alla prima domanda nel tuo contesto (I essendo PersonEditViewModel ) è sì. Pertanto, in qualche modo PersonEditViewModel deve ottenere l'istanza di Person appropriata. Si noti che "appropriato" è la chiave qui, ma consente di esaminarlo in un po '.

Venendo alla seconda domanda, chi è responsabile dell'istanziazione della classe Person ? È il tuo contenitore IoC? Io non la penso così Probabilmente caricherete un'istanza appropriata di Person di classe da un database o chiamando un servizio REST / WCF. In ogni caso, dovresti avere un altro tizio nell'equazione che è responsabile di darti la giusta istanza di Person . Se lo stai caricando dal database, quel tipo può essere un oggetto repository. In tal caso, la tua prossima dipendenza è il repository. Chiedi di nuovo lo stesso insieme di domande sul repository. La risposta al primo è ovviamente sì. Per quanto riguarda il secondo - il contenitore IoC può dare un'istanza di (avviso, non c'è "appropriato" qui) un repository. Sì, può. In modo che diventa la mia dipendenza.

Venendo a "Appropriato" - stai mettendo insieme questo modello di vista per una particolare istanza di persona. Questa particolare istanza di persona deve essere recuperata da qualche parte usando il giusto insieme di parametri come id, indirizzo email, nome ecc. Per eseguire quel lavoro è necessaria un'implementazione specializzata (repository ad esempio). Non puoi aspettarti che il contenitore IoC possa semplicemente idratare questo particolare oggetto per te in qualche modo.

score 0 · Answer 2

I contenitori DI sono generalmente utilizzati per collegare un numero limitato di oggetti longevi insieme. Pensa a loro come a costruire la struttura runtime del tuo programma. La persona mi sembra un'entità: verrà caricata, usata e scartata spesso. Inoltre, potresti potenzialmente avere un numero illimitato di oggetti Person e non avrebbe molto senso usare un contenitore per configurarli.

Ciò di cui hai probabilmente bisogno è PersonFactory e / o PersonRepository per la gestione del ciclo di vita degli oggetti Person. Questi possono essere configurati usando un contenitore. È quindi possibile avvolgere il factory / repository con un altro factory / repository che "inietta" la persona nel ViewModel. Gli altri servizi utilizzano quindi questo factory / repository per fare il loro lavoro.

Spero che ti aiuti un po '.