Gestione delle transazioni nidificate .NET

I tuoi negozi sembrano un livello aziendale, corretto? Suppongo che un determinato metodo nei negozi possa chiamare più repository per ottenere il suo lavoro, con tutto ciò che può essere ripristinato in caso di errore. In questo caso, il tuo negozio dovrebbe avviare la connessione e la transazione sql e consegnarli come dipendenze al repository.

All'interno di FooStore.cs:

public StoreResult<ResultThing> DoStuff(int stuff) 
{
     using (var connection = GetOpenConnection())
     using (var transaction = connection.BeginTransaction())
     {
          var fooRepo = new FooRepo(connection, transaction);
          fooRepo.DoThing(stuff); // calls connection.Execute(...)
          // add more repo calls here
          transaction.Commit();
          return new StoreResult<ResultThing>();
     }
}

Ora, StoreResult dovrà restituire alcuni tipi di dati di successo / fail / messaggistica per indicare al controller che lo ha chiamato quale tipo di risultato si è verificato.

Assegna alle classi "Store" un parametro booleano facoltativo del costruttore autocommit per controllare se devono gestire le transazioni da soli (ossia, commettere automaticamente dopo che il loro lavoro è stato eseguito), o se lasciano questo al chiamante. Il valore predefinito per questo parametro potrebbe essere true .

Quindi il tuo GroupsStore continuerà a commettere automaticamente per impostazione predefinita e anche il tuo UsersStore store, quando usato da solo.

Ora, per avere una transazione combinata "Gruppi e utenti", probabilmente creerai ancora una classe GroupsUsersStore separata, ma questa non deve più contenere alcun codice duplicato. Invece, può riutilizzare GroupsStore e UsersStore , chiamandoli entrambi con autocommit=false .

Sometimes I want to add users, and add them to a group - So If I had a GroupsStore, and a UsersStore - I now have a GroupsUsersStore that does exactly the same as those store, but by putting that in one transaction.

This is obviously wrong, but I can't think of a better solution - since transactions can't be nested in sql server, and I want those stores to work independently as well.

How do you solve such issue?

Penso che tu stia affrontando un problema dall'altra parte. Il controllo delle transazioni deve essere excersised solo su un livello applicativo. Quindi, se hai bisogno di controllare le transazioni a un livello più alto, di quanto fai ora, hai diverse scelte:

• Negozi di refactoring (in realtà sono servizi sembra) in modo che ognuno possa eseguire tutte le operazioni senza uscire dai limiti. Si potrebbe voler unire negozi, per esempio. Ma fai attenzione all'obidience SRP .
• Costruisci il livello di livello superiore della tua applicazione (livello di orchestrazione), che controllerà le transazioni e gli archivi delle chiamate quando necessario per eseguire un'operazione di bussiness.

So If I had a GroupsStore, and a UsersStore

Direi che hai bisogno di UserManager (o di qualsiasi altra cosa tu lo chiami), che può davvero gestire gli utenti come entità bussiness: assegnare utenti a gruppi ecc. Perché attualmente il tuo GroupsStore non è altro che un repository un po 'divino.