confini di transazione in un'architettura N-tier

Question

mi hanno un'architettura a 3 livelli che assomiglia più o meno in questo modo:

Cliente -> Affari -> Dati

Se operazioni dovrebbero iniziare idealmente?

Una scuola di pensiero dice che le transazioni dovrebbero iniziare solo nella parte superiore del livello dati. Il livello aziendale manipola solo gli oggetti business con la logica aziendale e non conosce mai le transazioni. L'azienda fa tutto il suo lavoro per manipolare gli oggetti e li consegna al livello dati per essere persistenti. È una filosofia un po 'RESTful applicata agli strati inferiori.

Un'altra scuola di pensiero dice che le transazioni dovrebbero iniziare nella parte superiore del livello aziendale. Il livello aziendale definisce le unità logiche di lavoro, non il livello dati, perché un'unità logica di lavoro a volte contiene la logica aziendale, non solo la logica dei dati.

Mi piace l'idea di spingere i problemi di transazione il più basso possibile. Tuttavia, ritengo che possa richiedere ulteriori sforzi e sfide progettuali per cercare di mantenere la logica aziendale fuori dal livello dati, a meno che non si tratti solo di operazioni CRUD. Se applichi modelli di progettazione RESTful con un martello, puoi farlo in modo che le tue applicazioni abbiano pochissime operazioni non CRUD.

C'è persino una terza scuola di pensiero che dice che il Cliente può avviare le transazioni in modo che possa combinare più operazioni aziendali quando è necessario. Ma ora il Cliente sta definendo l'unità di lavoro? Non è una questione di affari?

Una quarta scuola di pensiero afferma che i miei clienti possono essere solo componenti SOA che potrebbero partecipare a una transazione XA avviata anche al di fuori del client !!

I nostri sviluppatori vorrebbero alcuni standard più concreto di un semplice "Start transazioni ovunque ci si sente come"

Qualcuno ha qualche pareri o suggerimenti su questo argomento?

Grazie!

Answer 1

La transazione è un concetto di business e deve essere coordinata all'interno del Business Tier.

Manipolare gli oggetti in isolamento, in genere, offre pochi vantaggi e la manipolazione tra più tipi di oggetti è già una transazione. Quindi la prima scuola di pensiero si occupa di casi veramente elementari.

Quando il livello aziendale gestisce le transazioni, non importa chi inizia la transazione: client o altro servizio. Anche le transazioni a lungo termine (distribuite) possono essere supportate solo quando Business Tier ne è a conoscenza.

Answer 2

Nel

Cliente -> Affari -> Dati

architettura, è sempre meglio definire la transazione sul livello di business. Suggerirei che la transazione sia definita in modo tale che il servizio aziendale inizi una nuova transazione o partecipi alla transazione esistente se ne è già stata avviata. Questo si prende cura dei casi in cui un servizio aziendale è invocato da un altro servizio aziendale.

Avere il limite di transazione a livello di dati non riesce, se lo strato di business fanno più chiamate di livello dati come parte della stessa richiesta, come

client1-> business1 => data1, business1 => Data2