Come implementare il principio DRY quando si usa la parola chiave "using"?

Considera questi metodi:

public List<Employee> GetAllEmployees()
{
    using (Entities entities = new Entities())
    {
        return entities.Employees.ToList();
    }
}

public List<Job> GetAllJobs()
{
    using (Entities entities = new Entities())
    {
        return entities.Jobs.ToList();
    }
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    using (Entities entities = new Entities())
    {
        return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
    }
}

L'uso del blocco è lo stesso ed è stato ripetuto 3 volte qui (ovviamente, più di 100 volte nella vera applicazione). Come è possibile implementare l'entità DRY (Don't Repeat Yourself) per il usingblocco? È considerata una violazione del principio DRY?

Aggiornamento: non sto parlando di ciò che è stato implementato all'interno del usingblocco. Quello che in realtà intendo qui, è il using (Entities entities = new Entities()). Questa riga viene ripetuta 100 volte o più.

Un'idea sarebbe quella di avvolgerlo con una funzione che accetta a Func.

Qualcosa come questo

public K UsingT<T,K>(Func<T,K> f) where T:IDisposable,new()
{
    using (T t = new T())
    {
        return f(t);
    }
}

Quindi il codice sopra diventa

public List<Employee> GetAllEmployees()
{
    return UsingT<Entities,List<Employee>>(e=>e.Employees.ToList());
}

public List<Job> GetAllJobs()
{
    return UsingT<Entities,List<Job>>(e=>e.Jobs.ToList());
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    return UsingT<Entities,List<Task>>(e=>e.Tasks.Where(t => t.JobId == job.Id).ToList());
}

Ho anche creato Entitiesun parametro tipo, perché presumo che tu abbia più di un tipo con cui lo stai facendo. In caso contrario, è possibile rimuoverlo e utilizzare semplicemente il tipo param per il tipo restituito.

Ad essere onesti, anche se questo tipo di codice non aiuta affatto la leggibilità. Nella mia esperienza, più i colleghi Jr hanno avuto un momento davvero difficile.

Aggiorna Alcune variazioni aggiuntive sugli helper che potresti prendere in considerazione

//forget the Entities type param
public T UsingEntities<T>(Func<Entities,T> f)
{
    using (Entities e = new Entities())
    {
        return f(e);
    }
}
//forget the Entities type param, and return an IList
public IList<T> ListFromEntities<T>(Func<Entities,IEnumerable<T>> f)
{
    using (Entities e = new Entities())
    {
        return f(e).ToList();
    }
}
//doing the .ToList() forces the results to enumerate before `e` gets disposed.

Per me questo sarebbe come preoccuparsi di cercare più volte nella stessa collezione: è solo qualcosa che devi fare. Qualsiasi tentativo di astrarlo ulteriormente renderebbe il codice molto meno leggibile.

Sembra che tu stia confondendo il principio "Once and Only Once" con il principio DRY. Il principio DRY afferma:

Ogni pezzo di conoscenza deve avere un'unica, inequivocabile, autorevole rappresentazione all'interno di un sistema.

Tuttavia, il principio Once and Only Once è leggermente diverso.

Il principio [DRY] è simile a OnceAndOnlyOnce, ma con un obiettivo diverso. Con OnceAndOnlyOnce, sei incoraggiato a eseguire il refactoring per eliminare codice e funzionalità duplicati. Con DRY, si tenta di identificare la fonte unica e definitiva di ogni conoscenza utilizzata nel proprio sistema, quindi utilizzare tale fonte per generare istanze applicabili di tale conoscenza (codice, documentazione, test, ecc.).

Il principio DRY è di solito usato nel contesto della logica attuale, non tanto ridondante usando le istruzioni:

Mantenere la struttura di un programma DRY è più difficile e ha un valore inferiore. Sono le regole aziendali, le dichiarazioni if, le formule matematiche e i metadati che dovrebbero apparire in un solo posto. Le cose WET - pagine HTML, dati di test ridondanti, virgole e {} delimitatori - sono tutte facili da ignorare, quindi asciugarle è meno importante.

fonte

Non riesco a vedere l'uso di usingqui:

Che ne dite di:

public List<Employee> GetAllEmployees() {
    return (new Entities()).Employees.ToList();
}
public List<Job> GetAllJobs() {
    return (new Entities()).Jobs.ToList();
}
public List<Task> GetAllTasksOfTheJob(Job job) {
    return (new Entities()).Tasks.Where(t => t.JobId == job.Id).ToList();
}

O ancora meglio, poiché non credo che sia necessario creare un nuovo oggetto ogni volta.

private Entities entities = new Entities();//not sure C# allows for that kind of initialization, but you can do it in the constructor if needed

public List<Employee> GetAllEmployees() {
    return entities.Employees.ToList();
}
public List<Job> GetAllJobs() {
    return entities.Jobs.ToList();
}
public List<Task> GetAllTasksOfTheJob(Job job) {
    return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
}

Per quanto riguarda la violazione di DRY: DRY non si applica a questo livello. In realtà nessun principio lo fa davvero, tranne quello della leggibilità. Cercare di applicare DRY a quel livello è in realtà solo una micro-ottimizzazione architettonica, che come tutta la micro-ottimizzazione è solo una perdita di bici e non risolve alcun problema, ma rischia persino di introdurne di nuovi.
Dalla mia esperienza, so che se si tenta di ridurre la ridondanza del codice a quel livello, si crea un impatto negativo sulla qualità del codice, offuscando ciò che era veramente chiaro e semplice.

Modifica:
Ok. Quindi il problema non è in realtà l'istruzione using, il problema è la dipendenza dall'oggetto che si crea ogni volta. Suggerirei di iniettare un costruttore:

private delegate Entities query();//this should be injected from the outside (upon construction for example)
public List<Employee> GetAllEmployees() {
    using (var entities = query()) {//AFAIK C# can infer the type here
        return entities.Employees.ToList();
    }
}
//... and so on

Non solo l'utilizzo è un codice duplicato (tra l'altro è un codice duplicato e in realtà confronta con un'istruzione try..catch..finally) ma anche toList. Rifiuterei il tuo codice in questo modo:

 public List<T> GetAll(Func<Entities, IEnumerable<T>> getter) {
    using (Entities entities = new Entities())
    {
        return getter().ToList();
    }
 }

public List<Employee> GetAllEmployees()
{
    return GetAll(e => e.Employees);
}

public List<Job> GetAllJobs()
{
    return GetAll(e => e.Jobs);
}

public List<Task> GetAllTasksOfTheJob(Job job)
{
    return GetAll(e => e.Tasks.Where(t => t.JobId == job.Id));
}

Dal momento che qui non esiste alcuna logica aziendale di alcun tipo tranne l'ultima. Non è davvero ASCIUTTO, a mio avviso.

L'ultimo non ha alcun DRY nel blocco using ma immagino che la clausola where dovrebbe cambiare dove mai usata.

Questo è un lavoro tipico per i generatori di codice. Scrivi e copri il generatore di codice e lascialo generare per ogni tipo.

Dal momento che stai creando e distruggendo lo stesso oggetto usa e getta più volte, la tua classe è essa stessa un buon candidato per l'implementazione del modello IDisposable.

class ThisClass : IDisposable
{
    protected virtual Entities Context { get; set; }

    protected virtual void Dispose( bool disposing )
    {
        if ( disposing && Context != null )
            Context.Dispose();
    }

    public void Dispose()
    {
        Dispose( true );
    }

    public ThisClass()
    {
        Context = new Entities();
    }

    public List<Employee> GetAllEmployees()
    {
        return Context.Employees.ToList();
    }

    public List<Job> GetAllJobs()
    {
        return Context.Jobs.ToList();
    }

    public List<Task> GetAllTasksOfTheJob(Job job)
    {
        return Context.Tasks.Where(t => t.JobId == job.Id).ToList();
    }
}

Questo ti lascia solo bisogno di "usare" quando crei un'istanza della tua classe. Se non si desidera che la classe sia responsabile dello smaltimento degli oggetti, è possibile fare in modo che i metodi accettino la dipendenza come argomento:

public static List<Employee> GetAllEmployees( Entities entities )
{
    return entities.Employees.ToList();
}

public static List<Job> GetAllJobs( Entities entities )
{
    return entities.Jobs.ToList();
}

public static List<Task> GetAllTasksOfTheJob( Entities entities, Job job )
{
    return entities.Tasks.Where(t => t.JobId == job.Id).ToList();
}

Il mio pezzo preferito di magia incomprensibile!

public class Blah
{
  IEnumerable<T> Wrap(Func<Entities, IEnumerable<T>> act)
  {
    using(var entities = new Entities()) { return act(entities); }
  }

  public List<Employee> GetAllEmployees()
  {
    return Wrap(e => e.Employees.ToList());
  }

  public List<Job> GetAllJobs()
  {
    return Wrap(e => e.Jobs.ToList());
  }

  public List<Task> GetAllTasksOfTheJob(Job job)
  {
    return Wrap(e => e.Tasks.Where(x ....).ToList());
  }
}

Wrapesiste solo per sottrarre ciò o qualsiasi magia di cui hai bisogno. Non sono sicuro che lo consiglierei sempre, ma è possibile utilizzarlo. L'idea "migliore" sarebbe quella di utilizzare un contenitore DI, come StructureMap, e limitare l'ambito della classe Entities al contesto della richiesta, iniettarlo nel controller e quindi lasciare che si occupi del ciclo di vita senza che sia necessario il controller.