¿Cómo implementar el principio DRY cuando se usa la palabra clave 'using'?

Considere estos métodos:

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();
    }
}

Usar el bloque es igual y se ha repetido 3 veces aquí (por supuesto, más de 100 veces en la aplicación real). ¿Cómo es posible implementar el DRY (Don't Repeat Yourself) principal para el usingbloque? ¿Se considera una violación del director DRY?

Actualización: no estoy hablando de lo que se ha implementado dentro del usingbloque. Lo que realmente quiero decir aquí, es el using (Entities entities = new Entities()). Esta línea se repite 100 veces o más.

Una idea sería envolverlo con una función que tome a Func.

Algo como esto

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

Entonces su código anterior se convierte en

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());
}

También hice Entitiesun parámetro de tipo, porque supongo que tienes más de un tipo con el que estás haciendo esto. Si no lo está, puede eliminarlo y simplemente usar el tipo param para el tipo de retorno.

Para ser sincero, este tipo de código no ayuda en absoluto a la legibilidad. En mi experiencia, los compañeros de trabajo de Jr también lo pasan muy mal.

Actualización Algunas variaciones adicionales sobre los ayudantes que podría considerar

//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.

Para mí, esto sería como preocuparse por predecir la misma colección varias veces: es algo que debe hacer. Cualquier intento de abstraerlo aún más hará que el código sea mucho menos legible.

Parece que está confundiendo el principio "Once and Only Once" con el principio DRY. El principio DRY establece:

Cada conocimiento debe tener una representación autoritaria, inequívoca y única dentro de un sistema.

Sin embargo, el principio Once and Only Once es ligeramente diferente.

El principio [DRY] es similar a OnceAndOnlyOnce, pero con un objetivo diferente. Con OnceAndOnlyOnce, se le recomienda refactorizar para eliminar el código y la funcionalidad duplicados. Con DRY, intenta identificar la fuente única y definitiva de cada conocimiento utilizado en su sistema, y ​​luego usa esa fuente para generar instancias aplicables de ese conocimiento (código, documentación, pruebas, etc.).

El principio DRY generalmente se usa en el contexto de la lógica real, no tanto redundante usando declaraciones:

Mantener la estructura de un programa DRY es más difícil y de menor valor. Son las reglas de negocio, las declaraciones if, las fórmulas matemáticas y los metadatos que deberían aparecer en un solo lugar. Las cosas WET (páginas HTML, datos de prueba redundantes, comas y {} delimitadores) son fáciles de ignorar, por lo que SECARlas es menos importante.

Fuente

No veo el uso de usingaquí:

Qué tal si:

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 incluso mejor, ya que no creo que necesite crear un nuevo objeto cada vez.

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();
}

En cuanto a violar DRY: DRY no se aplica en este nivel. De hecho, ningún principio realmente lo hace, excepto el de legibilidad. Intentar aplicar DRY a ese nivel es realmente una microoptimización arquitectónica, que al igual que todas las microoptimizaciones es solo arrojar bicicletas y no resuelve ningún problema, pero incluso se arriesga a introducir otras nuevas.
Según mi propia experiencia, sé que si intentas reducir la redundancia de código a ese nivel, creas un impacto negativo en la calidad del código, al ofuscar lo que era realmente claro y simple.

Editar:
Ok. Entonces, el problema no es en realidad la declaración de uso, el problema es la dependencia del objeto que crea cada vez. Sugeriría inyectar un constructor:

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

No solo usar es código duplicado (por cierto, es código duplicado y en realidad se compara con una declaración try..catch..finally) sino también toList. Refactorizaría su código así:

 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));
}

Dado que no hay ninguna lógica de negocios de ningún tipo aquí, excepto la última. No es realmente SECO, en mi opinión.

El último no tiene DRY en el bloque de uso, pero supongo que la cláusula where debería cambiar donde sea que se haya usado.

Este es un trabajo típico para los generadores de código. Escriba y cubra el generador de código y déjelo generar para cada tipo.

Como está creando y destruyendo el mismo objeto desechable una y otra vez, su clase es en sí misma un buen candidato para implementar el patrón 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();
    }
}

Esto te deja solo necesitando el "uso" al crear una instancia de tu clase. Si no desea que la clase sea responsable de deshacerse de los objetos, puede hacer que los métodos acepten la dependencia como argumento:

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();
}

¡Mi parte favorita de magia incomprensible!

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());
  }
}

Wrapexiste solo para abstraer eso o cualquier magia que necesites. No estoy seguro de recomendarlo todo el tiempo, pero es posible usarlo. La idea "mejor" sería usar un contenedor DI, como StructureMap, y solo establecer el alcance de la clase Entities en el contexto de la solicitud, inyectarlo en el controlador y luego dejar que se ocupe del ciclo de vida sin que su controlador lo necesite.