Pattern del mediatore attraverso l'API web

Question

Pattern del mediatore attraverso l'API web

#1 da (1 voti)

0

Quali sono le tue opinioni sul modello di mediatore utilizzato da un cliente e attraverso una web API ?, questo significa:

Le definizioni dei comandi sono condivise tra il client e l'API.
Web api espone solo un metodo ExecuteCommand REST, che è cablato utilizzando il modello di mediazione ai gestori di comandi.
L'app client utilizza anche il modello di mediatore, il lavoro mediatore è di raggiungere l'API web (inviare la definizione del comando serializzato, ecc.).

Questo non è qualcosa che ho intenzione di fare o di cui ho bisogno, è solo un'idea e volevo leggere qualche feedback su di esso.

Mi sembra che sia come costruire un autobus di servizio. Forse utile su piccole app. La parte interessante di questo è la possibilità di introdurre facilmente la registrazione e le funzionalità simili sul link web api: hai un metodo API e un codice di connessione client.

In attesa di commenti. Sal.

Aggiornamento:

Ho fatto un proof of concept repo di questo per una migliore comprensione.

c# design-patterns web-api cqs

posta Salvador Sarpi 26.11.2018 - 20:27

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns web-api cqs

Modello di branching Git per team con fasi di sviluppo, test e distribuzione memoria virtuale non volatile per contenitori C ++

score 1 · Answer 1

Sì, in teoria è possibile creare un bus di servizio / evento tra il client e il server. Sebbene tu possa farlo tramite HTTP, credo che tu stia cercando WebSockets .

Diversi possibili vantaggi di questo sono:

distribuzione di servizi tra il computer client e il server. Senza sapere dove vivono i loro collaboratori.
la possibilità di incorporare ridondanza, ripristino, riposizionamento delle attività, elaborazione parallela.
la possibilità di vedere le comunicazioni avviene in tempo reale tra i servizi situati sull'altro computer.
Un'api molto semplificata.
Riduce la dipendenza da HTTP, consentendo il porting su altri protocolli di rete.

D'altra parte rende:

Gestione complessa dei messaggi distribuiti
Congestione del bus
Problemi di asincronia
Supporto di rete ridotto dall'architettura Web.

Il problema è che questo non è il modello di Mediatore.

Un mediatore non fornisce necessariamente un bus, né espone la comunicazione tra gli oggetti che collaborano.

Solo il mediatore è responsabile di sapere come organizzare la comunicazione tra questi oggetti e modificarlo in fase di esecuzione.

Potrebbe inviare alcune interazioni all'equivalente di /dev/null .
Altre interazioni possono essere estrapolate a centinaia di oggetti destinatari.
L'interazione stessa può essere trasformata in una serie diversa di interazioni.

È possibile creare due mediatori uno su entrambi i lati di questo bus di servizio. Sarebbero responsabili dell'interfaccia dei messaggi e delle interazioni, forse con alcune interazioni che venivano inoltrate direttamente ai contributori locali.

La riconfigurazione dei servizi in fase di esecuzione su scala non è sempre necessaria. Potrebbe essere più saggio utilizzare un modello di builder per costruire indipendentemente ciascun servizio. Costruito con un allegato al bus di servizio che viene chiuso quando viene eseguito il servizio (o il bus di servizio).