Iscriviti / Pubblica modello in applicazione basata su Web (c #) - Best practice per gestori di eventi

2

Recentemente sono stato esposto a un'applicazione desktop che utilizza un modello di pubblicazione / sottoscrizione per gestire comandi, eventi, ecc. Non riesco a trovare alcun buon esempio di utilizzo di questo in un'applicazione web, quindi mi chiedo se sono fuori base nel tentativo di utilizzare questo per lo sviluppo web based (sul lato server)? Sto usando asp.net c #.

La mia domanda principale riguardo al design è: Quando si utilizza un modello di pubblicazione / sottoscrizione, è meglio disporre di comandi / eventi generici che non trasmettono parametri e quindi che gli abbonati considerino gli oggetti di contesto statici che contengono i dati rilevanti per l'evento? O è meglio creare argomenti personalizzati per ogni evento che contiene dati relativi all'evento?

L'intero concetto di contenitore globale sembra così conveniente ma allo stesso tempo sembra interrompere l'incapsulamento.

Qualche idea o best practice da chiunque abbia implementato questo tipo di modello in un'applicazione basata sul web? Anche i suggerimenti su questo modello al di fuori della portata della mia domanda sono apprezzati.

    
posta KingOfHypocrites 02.03.2012 - 18:20
fonte

1 risposta

1

Per i pattern (pattern di osservatore, pubblicazione / sottoscrizione, pattern di visitatore) dove c'è una singola entità che parla o si occupa di più entità la comunicazione ha quello che io chiamo problema di lingua .

C'è qualcosa di simile a cui ho risposto che ti consiglio di leggere pattern Observer; sapendo * cosa * cambiato?

In sostanza, se si assegna un solo argomento o nessun argomento, il che significa che gli eventi vengono innescati e ricevuti come si desidera, ma non veicolano molto. Funziona bene per molti esempi banali. D'altro canto, se si tengono troppe informazioni diverse per ogni modulo - quindi sicuramente si sta creando qualcosa (come si chiama un container ) è solo un dumping di borse . Anche per un momento, se teniamo per un momento gli argomenti di violazione dell'incapsulamento, le bustine non sono buone. Per la prima parte, se hai un cliente in più e se il contenitore riceve un'ulteriore informazione, tutti gli altri clienti dovranno ignorare un altro campo (e ricompilare loro stessi)

Una parte del problema è che, mentre generalmente generalizziamo gli osservatori (cioè diversi oggetti concreti come osservatore e implementiamo observe() o notify() metodo) ma è ugualmente importante che la% ilnotification che deve essere dato a se stesso è una questione di astrazione. Dobbiamo chiedere - cosa devo notificare? e ancora più che cosa non devo notificare?

Considera un notificatore del mondo reale per capire questo:

1. Il primo di questa classe è broadcast type messages
* una notifica all'aeroporto informa su: voli in partenza arrivati e relativi orari.
* una bacheca del mercato azionario notifica: aggiornamenti su vari stock

La prima cosa da capire è che ciò che viene notificato è molto più stabile e molto facilmente comprensibile, e quindi, allegando un numero qualsiasi, il ricevitore non creerà mai un problema. I metadati sono ben definiti e, anche se dovesse essere modificato, è probabile che molti osservatori ne trarranno beneficio.

Quindi il problema linguistico in realtà non esiste nelle notifiche del tipo di trasmissione.

2. Lo scenario multicast o unicast in cui sono presenti messaggi specifici per obsever

Qualsiasi newsletter tipica o feed RSS o email sono piuttosto personali, ce ne sono anche e dai campi che portano il messaggio ai luoghi. Qui il messaggio può essere qualsiasi cosa - quindi per tutti gli scopi pratici, la trasmissione dei messaggi non ha in genere un singolo formato in grado di contenere tutte le informazioni - questo è un altro estremo a cui può evolvere un contenitore. Ad esempio, come nei casi di email , i metadati sono di nuovo standardizzati, ma nel corpo sono presenti molte informazioni significative ed è compito dell'osservatore finale / lettore interpretarle. il problema della lingua esiste qui, ma i canali (nel nostro caso l'API che trasporta le informazioni) devono essere liberi di interpretare questo. Lascia che la fonte in qualche modo crei un blob di informazioni e permetta all'osservatore di sapere cosa fare con il blob.

Quindi, in sostanza, quello che devi veramente fare è modellare la notifica - quale è veramente il contenuto del messaggio che deve essere in black box. l'essenza della risposta che ho fornito in questo link è che puoi creare una sorta di coppie generiche nome-valore o qualsiasi codifica generale dei messaggi e trasmettere. Può anche essere qualcosa come void* di C. Ma quell'esercizio è obbligatorio. D'altra parte, trova i metadati (come sorgente, data e ora, ecc.). Questi campi possono essere visibili a tutti i lettori di messaggi.

Un'ultima cosa da notare è, è fondamentale per qual è la responsabilità della fonte / editore e ciò che non è evitare personalizzazioni, estensioni alla definizione o al ruolo di editore per clienti specifici. Questa è l'unica fonte di divagazione nella maggior parte dei casi. Evita fino a che non arrivi ad un punto di perdere lo stipendio! :)

Fare tutto questo ti costringerà a fare più sforzi ma a salvarti dal debito tecnico di evolvere in un enorme tipo di contenitore di tipo sacco spazzatura e la maggior parte delle persone non riesce a capire perché questi le cose ci sono.

    
risposta data 03.03.2012 - 06:48
fonte

Leggi altre domande sui tag