Un flusso di lavoro di servizi imposto chiama un antipattern?

2

Abbiamo un'applicazione che utilizza molti servizi. Non appena l'applicazione viene avviata, dovrebbe chiamare un metodo di servizio web, "RegisterMachineSession". In questo metodo eseguiamo alcuni lavori di base che dovrebbero essere eseguiti prima di ogni altra chiamata di servizio. Ad esempio, carichiamo in memoria un set di parametri associati alla sessione della macchina che dovrebbe rimanere costante durante l'utilizzo dell'applicazione.

Mi sto chiedendo se non è un odore di codice perché ogni chiamata di servizio dovrebbe essere indipendente. È un antippaternismo noto o va bene perché abbiamo bisogno di un concetto di sessione?

    
posta Dypso 10.10.2017 - 23:01
fonte

2 risposte

1

In generale, un flusso di lavoro imposto implicherebbe che i tuoi servizi non siano apolidi. Statefulness non è necessariamente un anti-pattern ma è indesiderabile in quanto rende molto più difficile ridimensionare il tuo design. statelessness in questo contesto è la mancanza di stato del server tra le chiamate. Se si sposta lo stato della sessione su un database, ad esempio, non è considerato stato dal punto di vista del servizio. Se faccio 3 chiamate, non dovrebbe importare se sono soddisfatte da tre server diversi. Se riesci a eliminare le sessioni, è ancora meglio, ma in caso contrario, spostarle su un archivio dati condiviso elimina la maggior parte dei problemi.

Non sono sicuro di cosa fare "Ad esempio, carichiamo in memoria un set di parametri associati alla sessione della macchina che dovrebbe rimanere costante durante l'utilizzo dell'applicazione." È qualcosa che il cliente sta fornendo o è qualcosa che sta determinando il lato server?

Nel primo caso, può il client fornirlo per ogni chiamata? Il sovraccarico in più potrebbe valere la pena di eliminare lo stato lato server. Cosa ti impedisce di farlo quando viene chiamato il primo servizio "vero"?

Forse il ridimensionamento e la tolleranza ai guasti non sono di grande importanza in questo caso, ma rendere i servizi stateless semplificherà notevolmente la progettazione generale.

    
risposta data 11.10.2017 - 21:18
fonte
1

Spesso vedete i servizi fare o restituire qualcosa di necessario per una futura chiamata allo stesso servizio o ad un'altra. Ad esempio, ho bisogno di ottenere un elenco di utenti chiamando UserService e dopo alcuni filtri, quindi chiamo un secondo servizio OrdersService con un elenco di utenti. In questo non c'è assolutamente nulla di sbagliato in quanto ad ogni servizio viene dato esattamente tutto ciò che serve per fare il proprio lavoro senza stato.

Nel tuo esempio, tuttavia, mi sembra che RegisterMachineSession sia una sorta di apertura di un mezzo per chiamare altri servizi, che è certamente non stateless. Generalmente, se si dovesse fare una cosa del genere, si chiama semplicemente il servizio richiesto e, se necessario, il servizio stesso aprirà questa sessione per essere utilizzata in seguito. Ciò significa rendere un servizio stateful in un certo senso, tuttavia, questo è generalmente accettabile in quanto viene gestito internamente e al chiamante, lo stato è completamente trasparente (il chiamante non dovrebbe preoccuparsi se una chiamata precedente o meno ha aperto una sessione o altro).

Quindi secondo me, sì, è un anti-pattern.

    
risposta data 11.10.2017 - 08:15
fonte

Leggi altre domande sui tag