Pattern per più chiamate di servizio indipendenti

Question

Pattern per più chiamate di servizio indipendenti

#1 da (1 voti)
#2 da (-1 voti)

1

Ho una situazione attuale in cui devo progettare chiamate a più servizi web, provenienti da diverse aziende, diciamo EnrollFacebook, EnrollGoogle, EnrollYelp, EnrollBing.

Ho bisogno di costruire diverse opzioni che raggruppano queste iscrizioni, ad esempio:

PlanA: EnrollFacebook, EnrollGoogle, EnrollBing
PlanB: EnrollGoogle
PlanC: EnrollYelp, EnrollBing
PlanD: EnrollFacebook, EnrollGoogle, EnrollYelp, EnrollBing

In seguito, se avessi bisogno di creare un PlanE, voglio essere in grado di creare utilizzando le diverse unità (alias iscrizioni e plug google con yelp o qualsiasi altra cosa).

Sto indagando su un modello di progettazione che mi aiuta a coprirlo, dal momento che ogni iscrizione è un'unità indipendente, non sapendo che gli altri si iscrivono. Tuttavia, se una qualsiasi unità fallisce, devo chiamare tutto il deenroll relativo a tutte le registrazioni di successo.

Conosci uno schema adatto alle mie esigenze? Stavo leggendo su Pipeline o Mediator ma non sono sicuro che questo copra effettivamente ciò che descrivo.

Aggiornamento: ho letto questo post Scelta del modello di progettazione corretto , ma comunque questo non aiuta poiché so qual è il mio problema e sto solo cercando di trovare una soluzione esistente per questo problema poiché questo sembra un problema molto comune, non voglio reinventare la ruota se ci sono dei buoni progetti là fuori .

design design-patterns

posta Federico Piazza 14.04.2017 - 19:37

fonte

2 risposte

Leggi altre domande sui tag design design-patterns

Quale modello utilizza SLF4J? Qual è un buon approccio per fornire risultati di ricerca evidenziati in un database full text?

score 1 · Answer 1

La catena di responsabilità sembra essere un buon candidato per questo a prima vista:

un gestore può avere un successore opzionale, creando così il tipo di catena variabile che descrivi
la classe del gestore concreto implementerebbe un client di iscrizione

score -1 · Answer 2

Ti suggerisco di utilizzare l' iniezione delle dipendenze . Avere un file XML definire vari elementi di registrazione e elementi del piano.

<config>
    <plan name="PlanC">
        <enroll refId="EnrollYelp" order="0" attr1="val1" attr2="val2"/> 
        <enroll refId="EnrollBing" order="1" attr1="val1" attr2="val2"/> 
    </plan>
    <plan name="PlanA">
        <!-- more child enroll elements -->
    </plan>
    <enroll name ="EnrollGoogle" attr="val">
    </enroll>
    <enroll name ="EnrollYelp" attr="val">
    </enroll>
</config>

(È necessario creare uno schema che definisca la struttura precedente)

Ora la parte del codice. (Userò Java per descrivere cose)

Nel codice, puoi avere una classe Enroll e una classe Plan. La classe piano ha due code: enrollQueue e deenrollQueue

class Plan{
    Queue<Enroll> enrollQueue;
    Queue<Enroll> deEnrollQueue;
    // Other variables and methods follow
}

Avere metodi di registrazione e deenroll definiti nella classe Enroll:

class Enroll{
    String name;
    //other variables
    private boolean enroll(){
         // enroll logic might be based on attributes present in XML --
         // -- which were read by factory class and assigned into variables of this class.
         // return boolean indicating success of failure
    }
    private boolean deEnroll(){
         // enroll logic might depend on variables of this class which depend on attributes in XML element
         // return boolean indicating success of failure
    }
}

Hai anche una classe Factory che legge il file xml sopra definito e crea gli elementi Plan. Nella classe entrypoint / main / controller, crea i piani basati su xml

List<Plan> planList = PlanFactory.readPlansFromXML();

Ora per ogni piano nella lista piani, eseguire l'attività principale

for(Plan plan:planList){
    // get enroll queue for the plan
    // for each element in enroll queue
        // remove element from enroll queue and add it to deEnroll queue
        // execute enroll() for the element
        // if enroll() fails, execute deEnroll() for each element in deEnroll queue and break to next plan
        // if enroll() is successful, continue the loop with next element in enrollQueue
}

Poiché tutti i piani e tutte le iscrizioni sono definite in XML, puoi facilmente definire nuove registrazioni e nuovi piani semplicemente modificando l'XML senza alcuna modifica al codice.