Progettare attorno ai vincoli dei servizi esterni in un'architettura client-server

Naviga le tue risposte
4

Supponiamo di avere un client che si interfaccia con un server che a sua volta invoca un servizio esterno per soddisfare alcune richieste del cliente. Sto progettando il client e il server e ho bisogno di soddisfare i limiti del servizio esterno. Ho queste opzioni:

  1. Incapsula (il più possibile) tutto il codice che si occupa delle limitazioni del servizio all'interno dell'applicazione server .
  2. Incapsula (per quanto possibile) tutto il codice che si occupa delle limitazioni del servizio all'interno dell'applicazione client .
  3. Progetta sia le applicazioni client che quelle server intorno alle limitazioni del servizio esterno.

Avevo scelto l'opzione n. 1 perché l'applicazione server era "più vicina" al servizio esterno e non volevo dover riprogettare il client se e quando il servizio esterno fosse migliorato. Tuttavia, ora mi viene chiesto di scegliere l'opzione n. 3 dal team lato server in modo che possiamo gestire le limitazioni del servizio esterno nell'API invece di gestire le eccezioni. Esiste un modello di progettazione a cui posso fare riferimento per convincerli (o me stesso) che una opzione è preferibile? ( La separazione delle preoccupazioni sembra promettente, ma non mi sono convinto che sia sufficiente perché potrebbe anche argomentare sull'opzione n. 2 )

    
posta Stephen Rudolph 05.10.2011 - 18:17
fonte

2 risposte

3

# 1 è chiaramente la soluzione corretta.

Il client non dovrebbe sapere nulla sui dettagli di implementazione del server. L'aggiunta della conoscenza della topologia interna del server (che comunica con un servizio "esterno") viola il Principio di Responsabilità Unica e la Separazione di Preoccupazioni e accoppia il cliente ai dettagli dell'attuale implementazione interna del server.

Dal punto di vista del cliente, c'è solo un "servizio esterno": il server. Qualunque cosa il server faccia per calcolare la sua risposta per il client, è "interno" al server dal punto di vista del client. Cioè, il client deve considerare che il server è una scatola nera. Il client effettua richieste e ottiene risposte in base a qualsiasi protocollo implementato tra i due. Non dovrebbe sapere nulla su come il server crea quelle risposte.

    
risposta data 05.10.2011 - 18:42
fonte
1

IMHO entrambe le opzioni 1 e 3 finiranno probabilmente per sembrare allo stesso modo alla fine, a meno che l'applicazione server non abbia effettivamente una logica di business in grado di gestire le limitazioni del servizio esterno. In altre parole, i limiti del servizio Web esterno probabilmente influenzeranno l'interfaccia dell'applicazione server con il client, quindi il risultato finale potrebbe essere lo stesso.

Su quella nota che persegue 1 è ciò che DOVREBBE essere fatto. Il client non deve in alcun modo comunicare direttamente con il servizio Web esterno, l'unico client per il servizio Web esterno è l'applicazione server.

Lo scenario che descrivi è dove la maggior parte delle applicazioni software componentizzate vanno male e sviluppano odori di design . Il team delle applicazioni server si rifiuta di riconoscere che la logica aziendale che si integra con il servizio Web esterno è di loro responsabilità.

Sono stato in questa situazione prima e un certo numero di cose lo fanno:

  • Il team delle applicazioni server ignora lo sviluppo di software con componenti.

  • Il team di applicazioni server è sovraccarico e ha un programma serrato, cercando di spingere il lavoro di nuovo su altri team

  • Manager egoista che cerca di fuggire da ulteriori responsabilità per se stesso e il proprio team.

  • Il team di applicazioni del server è semplicemente pigro e vuole essere un intermediario vuoto tra il servizio web esterno e il proprio client.

risposta data 05.10.2011 - 18:55
fonte

Leggi altre domande sui tag

Powershell può fare tutto ciò che Iron Ruby non può fare? Le transazioni di rollback e roll-forward sono equivalenti per la tolleranza d'errore?