Iniezione callback

Question

Iniezione callback

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

1

Ho un servizio che deve effettuare una richiamata. Fondamentalmente, si tratta di un evento che dovrebbe essere gestito esattamente in un punto e che è troppo importante per essere facoltativo.

L'approccio ovvio sembra essere quello di iniettare un Action . Nel contesto dell'iniezione di dipendenza, è considerata una buona pratica (o accettabile) farlo?

Inoltre, desidero sentire perché (non) o quali alternative prendere in considerazione.

Un particolare problema che viene in mente è il seguente scenario:

Il costruttore di Parent prende un IChild .
Il costruttore di Child prende un Action , il callback.
Parent ha il metodo per ricevere il callback.
Per creare un'istanza di Child , abbiamo bisogno del metodo Parent , e quindi dell'istanza Parent . Ma per crearlo, abbiamo prima bisogno dell'istanza Child . Problema.

Una soluzione che posso pensare è iniettare un IChildFactory invece. Il costruttore di Parent può quindi utilizzare quella factory per creare l'istanza Child . A questo punto, esiste Parent , quindi può passare il suo metodo di callback alla produzione.

Questa soluzione sembra portare a termine il lavoro, ma sono curioso di alternative.

c# dependency-injection callbacks services circular-dependency

posta Timo 08.01.2018 - 12:23

fonte

2 risposte

Leggi altre domande sui tag c# dependency-injection callbacks services circular-dependency

Qual è l'architettura di sistema di un'applicazione reattiva non-SPA? Dati dinamici dei moduli persistenti

score 1 · Answer 1

Sì, l'iniezione di una richiamata è assolutamente accettabile. Di solito preferirei farlo in questo modo.

Un'alternativa, che hai già indicato, consiste nel definire un evento sull'oggetto servizio e utilizzare un factory per crearlo, assicurandosi che sia il modo solo di crearlo e quindi fare in modo che la fabbrica gestisca l'evento o lo deleghi ulteriormente (il che ci riporta al punto di partenza). ^*

L'esempio genitore / figlio specifico potrebbe avere altre soluzioni, a seconda del contesto. Ad esempio, puoi creare il genitore e passarlo al costruttore figlio, che potrebbe inserirsi come figlio del genitore.

_{* Chiarimento: il mio suggerimento era di o iniettare un callback o utilizzare una factory che registra un gestore di eventi nel modo normale. In questo caso, per far rispettare il requisito che l'evento deve essere gestito, solo la factory dovrebbe creare oggetti di servizio. Quindi nessuno può creare un oggetto di servizio senza registrare un gestore di eventi.}

_{Potresti voler utilizzare una factory anche con la callback inserita per altri motivi (ad esempio per assicurarti che sia fornita la callback correct ). Inoltre potresti avere più di queste fabbriche. Queste sono considerazioni separate.}

score 1 · Answer 2

Come per il commento di EmersonCardoso, potremmo iniettare il genitore nel figlio tramite l'iniezione di proprietà:

Il bambino viene iniettato in Parent, per iniezione del costruttore.
Nel costruttore di Parent, si imposta su una delle proprietà di Child.

Questo aiuta ad affrontare la natura ciclica delle dipendenze. La soluzione è simile a una proprietà di un evento pubblico, tranne che per un solo gestore.

Gli svantaggi potrebbero essere:

La dipendenza è diventata (in fase di compilazione) facoltativa.
Il bambino è diventato stato. I servizi stateless sono comunque una buona pratica, e ancora di più nel DDD, per esempio.
Il bambino è diventato esternamente mutabile. Anche se lo stato è ritenuto accettabile, la mutabilità esterna è qualcosa che eviterei.