Nel sourcing di eventi, è corretto introdurre una dipendenza nella mia classe di messaggi?

3

Dopo la spiegazione di Martin Fowler sul sourcing di eventi , ho una classe di messaggi che assomiglia a qualcosa del tipo:

ShippingEvent
{
    Process(Ship ship) {}
}

Tuttavia, nel mio caso, ho bisogno di parlare con un altro componente nel metodo Process . Più specifico, ho bisogno di accedere a un repository per ottenere alcuni dati di base. Va bene aggiungere questo repository al metodo, ad esempio:

ShippingEvent
{
    Process(Ship ship, IBasicDataRepository repo) {}
}

Potrei inserirlo anche nel costruttore del mio messaggio, ovviamente. Tuttavia, non posso passare i dati di base, perché il repository verrà chiamato più volte con parametri diversi, a seconda di cosa si trova nell'oggetto 'ship.

Quindi è corretto introdurre dipendenze esterne nella classe evento / messaggio o c'è un modo migliore?

    
posta Peter 28.04.2014 - 15:02
fonte

1 risposta

4

Penso che qualunque cosa stia ascoltando il tuo evento dovrebbe avere una dipendenza da un repository, invece di avere quella dipendenza all'interno del tuo messaggio.

Il tuo messaggio potrebbe essere utilizzato in diversi contesti e un repository aggiuntivo potrebbe non essere necessario ogni volta.

Suggerirei di mantenere gli eventi il più semplici possibile. I miei eventi normalmente trasferiscono una struttura dati. Un ascoltatore quindi preleva un evento e fa qualcosa con quella struttura dati.

Puoi implementare IShippingEventProcessor - questo avrebbe una dipendenza dal IBasicDataRepository .

Infine, gli eventi normalmente promuovono l'accoppiamento lento. Un singolo evento potrebbe essere pubblicato e quindi raccolto da una gamma di domini. Potrebbe accadere che uno dei domini non sappia nulla sulla dipendenza IBasicDataRepository .

    
risposta data 28.04.2014 - 15:42
fonte

Leggi altre domande sui tag