Comment implémenter le principe DRY lors de l'utilisation du mot-clé 'using'?

Considérez ces méthodes:

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'utilisation de block est la même et a été répétée 3 fois ici (bien sûr, plus de 100 fois dans l'application réelle). Comment est-il possible d'implémenter le principal DRY (Don't Repeat Yourself) pour le usingbloc? Est-ce considéré comme une violation du principe DRY?

Mise à jour: je ne parle pas de ce qui a été implémenté à l'intérieur du usingbloc. Ce que je veux dire ici, c'est le using (Entities entities = new Entities()). Cette ligne est répétée 100 fois ou plus.

Une idée serait de l'envelopper avec une fonction qui prend a Func.

Quelque chose comme ça

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

Ensuite, votre code ci-dessus devient

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

J'ai également fait Entitiesun paramètre de type, car je suppose que vous avez plus d'un type avec lequel vous faites cela. Si ce n'est pas le cas, vous pouvez le supprimer et utiliser simplement le paramètre de type pour le type de retour.

Pour être honnête, ce type de code n'aide en rien la lisibilité. D'après mon expérience, plus de collègues Jr ont également de la difficulté à le faire.

Mise à jour Quelques variantes supplémentaires sur les aides que vous pourriez envisager

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

Pour moi, cela reviendrait à s'inquiéter de devoir répéter plusieurs fois la même collection: c'est juste quelque chose que vous devez faire. Toute tentative de l'abréger rendrait le code beaucoup moins lisible.

On dirait que vous confondez le principe "Une seule et unique fois" avec le principe DRY. Le principe DRY stipule:

Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d'un système.

Cependant, le principe Once and Only Once est légèrement différent.

Le principe [SEC] est similaire à OnceAndOnlyOnce, mais avec un objectif différent. Avec OnceAndOnlyOnce, vous êtes encouragé à refactoriser pour éliminer le code et les fonctionnalités en double. Avec DRY, vous essayez d'identifier la source unique et définitive de chaque élément de connaissance utilisé dans votre système, puis utilisez cette source pour générer des instances applicables de cette connaissance (code, documentation, tests, etc.).

Le principe DRY est généralement utilisé dans le contexte d'une logique réelle, pas tellement redondant à l'aide d'instructions:

Garder la structure d'un programme SEC est plus difficile et de moindre valeur. Ce sont les règles métier, les instructions if, les formules mathématiques et les métadonnées qui ne doivent apparaître qu'à un seul endroit. Les éléments WET - pages HTML, données de test redondantes, virgules et délimiteurs {} - sont tous faciles à ignorer, il est donc moins important de les sécher.

La source

Je ne vois pas l'utilisation d' usingici:

Que diriez-vous:

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 encore mieux, car je ne pense pas que vous ayez besoin de créer un nouvel objet à chaque fois.

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 ce qui concerne la violation de DRY: DRY ne s'applique pas à ce niveau. En fait, aucun principe ne le fait vraiment, sauf celui de la lisibilité. Essayer d'appliquer DRY à ce niveau n'est en réalité que de la micro-optimisation architecturale, qui, comme toute micro-optimisation, n'est qu'un délestage de vélo et ne résout aucun problème, mais risque même d'en introduire de nouveaux.
D'après ma propre expérience, je sais que si vous essayez de réduire la redondance du code à ce niveau, vous créez un impact négatif sur la qualité du code, en obscurcissant ce qui était vraiment clair et simple.

Edit:
Ok. Ainsi, le problème n'est pas réellement l'instruction using, le problème est la dépendance à l'objet que vous créez à chaque fois. Je suggère d'injecter un constructeur:

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 seulement l'utilisation est du code en double (d'ailleurs, c'est du code en double et se compare en fait à une instruction try..catch..finally) mais aussi la toList. Je voudrais refactoriser votre code comme ceci:

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

Puisqu'il n'y a ici aucune logique commerciale, à l'exception de la dernière. Ce n'est pas vraiment SEC, à mon avis.

Le dernier n'a pas de DRY dans le bloc using mais je suppose que la clause where devrait changer où qu'elle soit utilisée.

Il s'agit d'un travail typique pour les générateurs de code. Écrire et couvrir le générateur de code et le laisser générer pour chaque type.

Puisque vous créez et détruisez le même objet jetable encore et encore, votre classe est elle-même un bon candidat pour implémenter le modèle 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();
    }
}

Cela vous laisse seulement besoin de «utiliser» lors de la création d'une instance de votre classe. Si vous ne voulez pas que la classe soit responsable de l'élimination des objets, vous pouvez faire en sorte que les méthodes acceptent la dépendance comme argument:

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

Mon morceau préféré de magie incompréhensible!

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

Wrapn'existe que pour en faire abstraction ou quelle que soit la magie dont vous avez besoin. Je ne suis pas sûr de le recommander tout le temps, mais il est possible de l'utiliser. La "meilleure" idée serait d'utiliser un conteneur DI, comme StructureMap, et d'étendre simplement la classe Entities au contexte de la demande, de l'injecter dans le contrôleur, puis de le laisser s'occuper du cycle de vie sans que votre contrôleur n'en ait besoin.