Scrivere esplicitamente usando (...) {...} o nascondendolo?

Dal modo in cui descrivi il tuo codice, sembra che PersonWorkUnit abbia un insieme di metodi che seguono tutti il seguente formato:

public SomeType Foo(...) 
{
    using(var context = this.contextFactory.Create<IPersonContext>())
    {
        var personRepo = this.repositoryFactory.Create<IPersonRepository>(context);
        // do something with personRepo to create SomeType instance
        // return SomeType
    }
}

Se questo è il caso, usa semplicemente i delegati per creare un singolo metodo che faccia tutto ciò che esclude le righe commentate e forniscile con un Func<> :

public Person Get(int id) => ProcessPersonRepo(p => p.Get(id));

private T ProcessPersonRepo<T>(Func<IPersonRepository, T> specificBehaviour) 
{
    using(var context = contextFactory.Create<IPersonContext>())
    {
        var personRepo = repositoryFactory.Create<IPersonRepository>(context);
        return specificBehaviour(personRepo);
    }
}

Forse è solo il tuo esempio ma questo codice mi sembra strano. un odore di codice, se vuoi.

Hai quattro oggetti che hanno il controllo possibile della connessione db

• La fabbrica del contesto
• Il repository
• L'unità di lavoro
• Il contesto stesso

Posso capire perché potresti volere tutto questo, ma è una configurazione piuttosto complessa.

Sono sicuro che il tuo esempio è intenzionalmente limitato, ma solleva alcune domande sui possibili modi per semplificare il codice.

• Se i metodi dell'unità di lavoro rispecchiano i repository, perché non li hanno affatto? Basta chiamare il repository.

• Il factory di contesto potrebbe non essere parte del repository? Forse usa un costruttore di stringhe di connessione.

• Quale valore viene aggiunto creando un nuovo repository su ogni chiamata? Non potresti semplicemente iniettare il repository?

• Se i metodi della tua unità di lavoro sono più grandi dell'esempio, Transaction Scope sarebbe un metodo alternativo per controllare l'unità?

Se il tuo codice di vita reale giustifica l'uso di tutti e quattro gli oggetti e ognuno ha una chiara responsabilità, allora:

Sì, la sua buona pratica è quella di eliminare il contesto dopo l'uso e ...

No, direi che spostare il blocco usando ad un Aspect Orientated Attribute getta semplicemente un'altra complessità in uno scenario già complesso e offusca invece di semplificare il codice.

Affrontare il contesto e gli oggetti del repository sono preoccupazioni relative al livello di accesso ai dati e devono essere separati dai propri oggetti di business, che è ciò che appare PersonWorkUnit. Dovresti avere una classe di accesso ai dati che gestisce solo l'utilizzo del contesto e del repository. questo renderebbe più semplice il tuo codice aziendale avendo solo qualcosa come dataGetter.GetPerson(Id); nel tuo metodo get. Se conosci la persona di cui hai bisogno alla creazione di PersonWorkUnit, puoi anche spostare questa chiamata al costruttore che semplificherà il codice che chiama anche PersonWorkUnit. Tutto il brutto codice della piastra della caldaia è quindi in dataGetter dove può essere ignorato per la maggior parte.

L'obiettivo di questa configurazione è mantenere la separazione dei problemi, in modo che la logica aziendale non debba gestire la logica dell'infrastruttura e consente inoltre di seguire il principio di open closed. con il tuo progetto di esempio PersonWorkUnit deve cambiare se le regole di accesso ai dati cambiano e se cambiano le regole aziendali sulla persona. Avendo una classe dataGetter che restituisce una persona, l'unica ragione per cui PersonWorkUnit deve essere modificata è perché la logica aziendale cambia.