Como implementar o princípio DRY ao usar a palavra-chave 'using'?

Considere estes 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 bloco é o mesmo e foi repetido 3 vezes aqui (é claro, mais de 100 vezes no aplicativo real). Como é possível implementar o princípio DRY (Don't Repeat Yourself) para o usingbloco? É considerado uma violação do principal DRY?

Atualização: não estou falando sobre o que foi implementado dentro do usingbloco. O que eu realmente quero dizer aqui é o using (Entities entities = new Entities()). Esta linha é repetida 100 vezes ou mais.

Uma idéia seria envolvê-lo com uma função que leva a Func.

Algo assim

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

Então o seu código acima se torna

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

Também fiz Entitiesum parâmetro de tipo, porque estou assumindo que você tem mais de um tipo com o qual está fazendo isso. Caso contrário, você pode removê-lo e apenas usar o parâmetro param para o tipo de retorno.

Para ser sincero, esse tipo de código não ajuda na legibilidade. Na minha experiência, os colegas de trabalho Jr também enfrentam dificuldades.

Atualizar Algumas variações adicionais nos ajudantes que você pode 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 mim, isso seria como se preocupar em procurar a mesma coleção várias vezes: é apenas algo que você precisa fazer. Qualquer tentativa de abstraí-lo tornaria o código muito menos legível.

Parece que você está confundindo o princípio "Uma vez e apenas uma vez" com o princípio DRY. O princípio DRY afirma:

Todo conhecimento deve ter uma representação única, inequívoca e autoritativa dentro de um sistema.

No entanto, o princípio Uma vez e Somente uma vez é um pouco diferente.

O princípio [DRY] é semelhante ao OnceAndOnlyOnce, mas com um objetivo diferente. Com o OnceAndOnlyOnce, é recomendável refatorar para eliminar o código e a funcionalidade duplicados. Com o DRY, você tenta identificar a fonte única e definitiva de todo conhecimento utilizado em seu sistema e, em seguida, usa essa fonte para gerar instâncias aplicáveis ​​desse conhecimento (código, documentação, testes, etc.).

O princípio DRY é geralmente usado no contexto da lógica real, não tão redundante usando instruções:

Manter a estrutura de um programa SECO é mais difícil e tem menor valor. São as regras de negócios, as instruções if, as fórmulas matemáticas e os metadados que devem aparecer em apenas um lugar. O material WET - páginas HTML, dados de teste redundantes, vírgulas e {} delimitadores - é fácil de ignorar; portanto, SECAR é menos importante.

Fonte

Não vejo o uso de usingaqui:

E se:

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

Ou melhor ainda, pois acho que você não precisa criar um novo objeto todas as vezes.

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

Quanto à violação de DRY: DRY não se aplica a este nível. De fato, nenhum princípio realmente existe, exceto o da legibilidade. Tentar aplicar o DRY nesse nível é realmente apenas uma micro-otimização arquitetônica, que, como toda micro-otimização, é apenas uma troca de bicicletas e não soluciona nenhum problema, mas corre o risco de introduzir novos.
Pela minha própria experiência, sei que se você tentar reduzir a redundância de código nesse nível, criará um impacto negativo na qualidade do código, ofuscando o que era realmente claro e simples.

Edit:
Ok. Portanto, o problema não é realmente a instrução using, o problema é a dependência do objeto que você cria todas as vezes. Eu sugeriria injetar um construtor:

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

Não apenas o uso é de código duplicado (a propósito, ele é código duplicado e, na verdade, se compara a uma instrução try..catch..finally), mas também a toList. Eu refatoraria seu código assim:

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

Como não há lógica comercial de qualquer tipo aqui, exceto a última. Não é realmente SECO, na minha opinião.

O último não possui DRY no bloco using, mas acho que a cláusula where deve mudar onde quer que seja usada.

Este é um trabalho típico para geradores de código. Escreva e cubra o gerador de código e deixe-o gerar para cada tipo.

Como você está criando e destruindo o mesmo objeto descartável repetidamente, sua própria classe é um bom candidato para implementar o padrão 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();
    }
}

Isso deixa você apenas precisando do "using" ao criar uma instância da sua classe. Se você não deseja que a classe seja responsável por descartar os objetos, faça com que os métodos aceitem a dependência 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();
}

Minha parte favorita de magia incompreensível!

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 apenas para abstrair isso ou qualquer mágica que você precisa. Não tenho certeza se recomendaria isso o tempo todo, mas é possível usá-lo. A idéia "melhor" seria usar um contêiner de DI, como StructureMap, e apenas colocar a classe Entities no contexto da solicitação, injetá-la no controlador e, então, cuidar do ciclo de vida sem a necessidade de seu controlador.