Transaction Design Pattern per MVC e posizione di responsabilità?

Trovo utile implementare una facciata di servizio che disaccoppia l'implementazione dei servizi dal contratto di servizio. Il Controller dal livello di presentazione (il tuo materiale MVC) dovrebbe essere in grado di effettuare una singola chiamata a una facciata di servizio, che quindi orchestra le chiamate verso uno o più oggetti / metodi "di servizio" e restituisce qualsiasi cosa il contratto di servizio dice che ha bisogno di tornare.

In questa architettura, la facciata di servizio sarebbe anche il punto in cui agganciare la gestione delle transazioni.

Sono a conoscenza del fatto che il responsabile del trattamento dovrebbe essere principalmente responsabile della comunicazione con il livello aziendale e della preparazione dei dati di visualizzazione quando necessario. In tal caso, non dovrebbe avere alcuna conoscenza sulle transazioni; dovrebbero essere conservati in uno strato inferiore.

Quando il controller deve eseguire una logica che consiste in più passaggi in cui si desidera una singola transazione, tale logica deve essere implementata in un metodo nel livello aziendale. Quando gestisci le transazioni con Spring , puoi facilmente definire un metodo di servizio come transazionale e in che modo le chiamate nidificate devono gestire le loro transazioni: se raccogliere la transazione esistente se disponibile, creare sempre nuove, ecc.

Il livello di servizio è il posto più adatto per la demarcazione delle transazioni nelle app MVC, indipendentemente dal pattern del livello di servizio che si utilizza.

Tuttavia, a volte le concessioni dovrebbero essere fatte per un'applicazione specifica quando ha senso, quindi non ne sarei eccessivamente dogmatico. Assicurati solo di utilizzare la gestione dichiarativa delle transazioni in modo da poter spostare le transazioni nella posizione più appropriata senza influire sul codice dell'applicazione.