Il pattern stesso non prescrive realmente come gestirlo.
La mia preferenza è un hub di messaggi/eventi in cui i presentatori possono registrare interessi in determinati eventi. Previene gli alberi di dipendenza complessi e mantiene i relatori testabili.
Ad esempio:
class PresenterA
{
void HandleProductSelectionChanged(int productId)
{
EventHub.Publish(EventType.ProductChanged, productId);
}
}
class PresenterB
{
void PresenterB
{
EventHub.Register(EventType.ProductChanged, HandleProductChanged);
}
public void HandleProductChanged(object state)
{
var productId = (int)state;
var productDetails = LoadProductDetails(productId);
view.DisplayProductDetails(productDetails);
}
}
EventHub avrebbe mantenuto un elenco di iscritti per invocare per ogni tipo di evento.
È possibile mantenere la testabilità - è sufficiente chiamare il numero HandleProductChanged
per vedere come PresenterB risponderebbe a una nuova selezione di prodotti.
L'unico svantaggio (come con qualsiasi modello) è introdurre un livello di riferimento indiretto. Se PresenterA ha invocato direttamente PresenterB, o PresenterB ha ascoltato un evento su PresenterA, è immediatamente ovvio cosa succederà.
In questo approccio, avresti il passaggio in più per vedere EventType.ProductChanged, e quindi trovare quali Presentatori hanno registrato un interesse per quell'evento.
Nella mia esperienza personale, l'unico livello di riferimento indiretto merita la modularità.
fonte
2012-03-19 00:11:31
Questo è esattamente quello che stavo cercando, sembra molto meglio che passare i riferimenti del relatore in giro. Domani darò un'occhiata a me quando non sono stanco. Grazie. – user1277327