Flusso di lavoro dell'applicazione

1

Sono nel processo di pianificazione per una nuova applicazione, l'applicazione sarà scritta in PHP (usando il framework Symfony 2) ma non sono sicuro di quanto sia rilevante. L'applicazione sarà basata su browser, anche se alla fine ci sarà l'accesso API per altri sistemi per interagire con i dati memorizzati all'interno dell'applicazione, probabilmente ancora non relavent a questo punto.

L'applicazione gestisce le schede SIM per molti fornitori diversi: ogni scheda SIM appartiene a un singolo fornitore, ma un singolo cliente potrebbe avere molte carte SIM in più provider. L'applicazione consente all'utente di eseguire azioni contro la carta SIM, ad esempio attivarla, barrarla, controllarne lo stato ecc.

Alcuni provider forniscono un'API per farlo - quindi un singolo punto di accesso con più metodi, ad esempio activateSIM , getStatus , barrSIM ecc. I nomi dei metodi differiscono per ciascun provider e alcuni provider offrono metodi per extra funzioni che gli altri non fanno. Alcuni provider non hanno API ma offrono questi metodi inviando email con allegati - gli allegati sono normalmente un file CSV che contiene il riferimento e l'azione SIM richiesti - l'email è elaborata dal provider e ha risposto una volta che l'azione è stata completata .

Per fare un esempio: il front-end della mia applicazione fornirà al cliente un elenco di carte SIM di sua proprietà e darà loro accesso alle azioni fornite dal fornitore di ciascuna scheda SIM specifica - alcuni metodi potrebbero richiedere dati extra che verranno memorizzati nel back-end o raccolti dal frontend dell'utente. Una volta che l'utente ha selezionato la propria azione e aggiunto i dati richiesti, gestirò il processo nel back-end e fornirò un feedback immediato, nel caso dei provider con API, o avvierà il processo inviando un'email e attendendo la sua risposta prima elaborandolo e aggiornando il back-end in modo che la volta successiva che l'utente verifichi la scheda SIM, il suo stato è corretto (cioè aggiornato da un processo di back-end).

Il motivo per cui ho creato questa domanda è perché sono bloccato !! Sono confuso su come affrontare la logica del flusso di lavoro reale. Stavo pensando di creare un'interfaccia provider con i metodi più comuni getStatus , activateSIM e barrSIM e quindi implementando quell'interfaccia per ciascun provider. Quindi class Provider1 implements Provider - Quindi usa una Fabbrica per creare la classe richiesta in base alla carta SIM selezionata dall'utente e invocando il metodo selezionato. Ciò funzionerebbe bene se tutti i provider offrissero gli stessi metodi ma non lo facessero - esiste un sottoinsieme che è comune ma alcuni provider offrono metodi aggiuntivi - come posso implementarlo in modo flessibile? Come posso gestire i processi in cui il flusso di lavoro è diverso - ad esempio alcuni metodi richiedono e la chiamata e il valore dell'API restituiti e alcuni richiedono l'invio di una e-mail e la fase successiva del processo non inizia fino a quando non viene ricevuta la risposta via e-mail. .

Per favore aiuto! (Spero che questa sia una domanda leggibile e che questo sia il posto giusto da chiedere)

Aggiorna

Immagino che quello che sto cercando di evitare sia una grande if o switch / case statement - qualche schema di progettazione che mi dà un approccio flessibile all'implementazione di questo tipo di flusso di lavoro fluido .. qualcuno?

    
posta ManseUK 23.11.2012 - 20:09
fonte

2 risposte

2

Vorrei iniziare definendo un'API di base che ritieni di poter supportare in tutti i tuoi fornitori. Successivamente è possibile estendere con metodi opzionali e controlla per informarti sulle azioni supportate da determinati provider. Ma questo è sicuramente uno stage 2.

L'API principale deve essere asincrona perché alcuni provider non rispondono ai loro metodi in un tempo ragionevole. Ad esempio puoi launchSomeRequest che inserirà i dati in una tabella dicendo che la richiesta è stata fatta (in modo da poter gestire i doppi clic), quindi offrire checkSomeRequest che controlla la tabella per dire se è stata eseguita.

Dietro le quinte ogni richiesta archiviata registra il provider e le informazioni che consentono di effettuare la richiesta effettiva. Puoi quindi avere un cron job che si attiva regolarmente, cerca le richieste e fa l'azione vera e propria.

(Nota, la mia esperienza con le architetture push-pull mi induce a preferire sistemi di pull come questo. Sono più lenti e meno efficienti, ma le loro modalità di errore sono molto migliori.)

Se si utilizza questa strategia, il primo passo consiste nel riflettere su quel minimo comune denominatore iniziale e capire quali informazioni devono essere memorizzate nel proprio back-end per farlo funzionare (che presumo sia una sorta di database ). Codice in su. Codifica almeno due backend molto diversi. (Questo è un buon modo per eliminare le ipotesi che potresti aver fatto.) Quindi puoi lavorare sul tuo front-end e iniziare lentamente ad aggiungere altri back-end.

Solo allora inizi a pensare di aggiungere parti facoltative dell'API.

    
risposta data 23.11.2012 - 21:40
fonte
0

Raccomando di pensare in casi d'uso. Ad esempio, un caso d'uso è "Attiva scheda SIM". Creare un'interfaccia come ActivateSimCardController o ActivteSimCardInteractor. Le implementazioni di questa interfaccia sono specifiche per ogni fornitore di SIM card. Per creare la corretta implementazione è necessario un identificativo per il provider, quindi è necessario eseguire un'implementazione davanti al controller per scegliere quello giusto oppure salvare tutte le azioni possibili insieme al provider. Il cliente sceglierà il servizio specifico del provider nel secondo caso.

Tutti i servizi non dovrebbero restituire nulla, perché hai questo back-end email. Il cliente deve chiamare un GetStatusOfActivateSimCardController per ottenere il risultato. In questo modo è possibile implementare lo stesso meccanismo per tutti i provider.

    
risposta data 23.11.2012 - 21:50
fonte

Leggi altre domande sui tag