Pattern di progettazione per il controllo dell'interfaccia utente e il provider per chiamare gli eventi di controllo [chiuso]

Question

Pattern di progettazione per il controllo dell'interfaccia utente e il provider per chiamare gli eventi di controllo [chiuso]

#1 da (2 voti)

1

Ho un controllo dell'interfaccia utente che utilizza una classe provider per implementare la logica effettiva di un'attività complessa. Quindi il controllo delega al fornitore per fare un po 'di lavoro. Ma il fornitore deve anche lavorare con il controllo; ha bisogno di sparare alcuni eventi sul controllo.

Stavo cercando un buon modello di progettazione di come i due potessero lavorare insieme, ma non ne ero sicuro. Non volevo che il provider invocasse direttamente eventi sul controllo. Ho pensato a metodi sul controllo che poteva chiamare, ma non so nemmeno che mi piaccia.

Qualche idea, pensieri? Qual è un buon modello di progettazione che il provider può utilizzare per attivare una notifica attraverso il controllo? Ogni evento può anche aver bisogno di passare anche i parametri personalizzati.

design-patterns ui

posta Brian Mains 15.07.2011 - 19:36

fonte

1 risposta

Leggi altre domande sui tag design-patterns ui

progetto di database open source Strategia per proteggere dati a pagamento come API di servizio

score 2 · Accepted Answer

Posso pensare a due modelli:

Utilizzo delle funzioni di callback

Se la tua lingua supporta passando le funzioni come parametri , puoi chiamare il metodo del fornitore dall'interfaccia utente, passandole una funzione da eseguire nel punto appropriato. C # e JavaScript supportano questo metodo. Il codice può essere qualcosa del tipo:

provider.DoSomething(successCallback);
function successCallback () {
    // This function is written in UI and belongs to UI, but would be executed in provider.
}

Uso degli eventi

In questo modello, puoi esporre eventi personalizzati nel tuo provider al mondo esterno. In questo modo, puoi fornire gestori di eventi per quegli eventi nell'interfaccia utente. Ad esempio, immagina che un provider tenti di convalidare un ordine. Questo provider può esporre un evento chiamato OrderValidated al mondo esterno e l'interfaccia utente è solo qualcosa che esiste in quel mondo esterno. L'interfaccia utente invece può fornire un gestore per quell'evento chiamato HandleOrderValidated . Infatti, l'interfaccia utente sottoscrive un interessante momento del ciclo di vita interno del provider e quando quel momento interessante arriva alla realtà, il provider informa ogni sottoscrittore e ciascun iscritto prende la sua azione.