Wie implementiere ich das DRY-Prinzip, wenn ich das Schlüsselwort 'using' verwende?

Betrachten Sie diese Methoden:

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

Die Verwendung von Block ist dieselbe und wurde hier dreimal wiederholt (natürlich mehr als 100 Mal in der realen Anwendung). Wie ist es möglich, ein DRY-Prinzip (Don't Repeat Yourself) für einen usingBlock zu implementieren ? Gilt es überhaupt als Verstoß gegen den DRY-Grundsatz?

Update: Ich spreche nicht darüber, was innerhalb des usingBlocks implementiert wurde . Was ich hier eigentlich meine, ist das using (Entities entities = new Entities()). Diese Zeile wird mindestens 100 Mal wiederholt.

Eine Idee wäre, es mit einer Funktion zu umschließen, die a annimmt Func.

Etwas wie das

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

Dann wird Ihr oben genannter Code

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

Ich habe auch Entitieseinen Typ-Parameter erstellt, da ich davon ausgehe, dass Sie mehr als einen Typ haben, mit dem Sie dies tun. Wenn dies nicht der Fall ist, können Sie es entfernen und einfach den type-Parameter für den Rückgabetyp verwenden.

Um ehrlich zu sein, trägt diese Art von Code überhaupt nicht zur Lesbarkeit bei. Nach meiner Erfahrung haben es auch die mehr Jr.-Mitarbeiter sehr schwer.

Aktualisieren Sie einige zusätzliche Variationen der Helfer, die Sie möglicherweise in Betracht ziehen

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

Für mich wäre das, als würde man sich mehrmals darum sorgen, dieselbe Sammlung zu durchsuchen: Es ist nur etwas, was man tun muss. Jeder Versuch, ihn weiter zu abstrahieren, würde den Code viel weniger lesbar machen.

Es hört sich so an, als würden Sie das Prinzip "Einmal und nur einmal" mit dem DRY-Prinzip verwechseln. Das DRY-Prinzip lautet:

Jedes Wissen muss eine einzige, eindeutige und maßgebliche Repräsentation innerhalb eines Systems haben.

Das Prinzip von einmal und nur einmal unterscheidet sich jedoch geringfügig.

Das Prinzip [DRY] ähnelt dem von OnceAndOnlyOnce, hat jedoch ein anderes Ziel. Mit OnceAndOnlyOnce werden Sie aufgefordert, Änderungen vorzunehmen, um doppelten Code und doppelte Funktionen zu beseitigen. Mit DRY versuchen Sie, die einzige, endgültige Quelle für jedes in Ihrem System verwendete Wissen zu identifizieren und diese Quelle dann zu verwenden, um anwendbare Instanzen dieses Wissens zu generieren (Code, Dokumentation, Tests usw.).

Das DRY-Prinzip wird normalerweise im Kontext der eigentlichen Logik verwendet, nicht so sehr redundant mit Anweisungen:

Das Beibehalten der Struktur eines Programms DRY ist schwieriger und hat einen niedrigeren Wert. Es sind die Geschäftsregeln, die if-Anweisungen, die mathematischen Formeln und die Metadaten, die an nur einer Stelle angezeigt werden sollen. Die WET-Inhalte - HTML-Seiten, redundante Testdaten, Kommas und Trennzeichen - können leicht ignoriert werden. Daher ist es weniger wichtig, sie zu trocknen.

Quelle

Ich kann die Verwendung von usinghier nicht erkennen:

Wie wäre es mit:

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

Oder noch besser, da ich nicht denke, dass Sie jedes Mal ein neues Objekt erstellen müssen.

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

Was die Verletzung von DRY angeht: DRY gilt auf dieser Ebene nicht. Tatsächlich gibt es kein Prinzip, außer dem der Lesbarkeit. Der Versuch, DRY auf dieser Ebene anzuwenden, ist eigentlich nur eine architektonische Mikrooptimierung, die wie jede Mikrooptimierung nur einen Fahrradabwurf darstellt und keine Probleme löst, sondern sogar das Risiko birgt, neue einzuführen.
Aus eigener Erfahrung weiß ich, dass Sie, wenn Sie versuchen, die Code-Redundanz auf dieser Ebene zu verringern, die Code-Qualität negativ beeinflussen, indem Sie das verschleiern, was wirklich klar und einfach war.

Bearbeiten:
Ok. Das Problem ist also nicht die using-Anweisung, sondern die Abhängigkeit von dem Objekt, das Sie jedes Mal erstellen. Ich würde vorschlagen, einen Konstruktor zu injizieren:

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

Es wird nicht nur doppelter Code verwendet (übrigens ist es doppelter Code und wird tatsächlich mit einer try..catch..finally-Anweisung verglichen), sondern auch die toList. Ich würde Ihren Code so umgestalten:

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

Da es hier außer der letzten keine Geschäftslogik gibt. Meiner Meinung nach ist es nicht wirklich trocken.

Der letzte hat kein DRY im using-Block, aber ich denke, die where-Klausel sollte sich ändern, wo immer sie verwendet wird.

Dies ist ein typischer Job für Codegeneratoren. Schreiben und decken Sie den Codegenerator ab und lassen Sie ihn für jeden Typ generieren.

Da Sie immer wieder dasselbe Einwegobjekt erstellen und zerstören, ist Ihre Klasse selbst ein guter Kandidat für die Implementierung des IDisposable-Musters.

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

Das bedeutet, dass Sie nur das "using" benötigen, wenn Sie eine Instanz Ihrer Klasse erstellen. Wenn Sie nicht möchten, dass die Klasse für die Disposition der Objekte verantwortlich ist, können Sie die Methoden veranlassen, die Abhängigkeit als Argument zu akzeptieren:

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

Mein Lieblingsteil der unverständlichen Magie!

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

Wrapexistiert nur, um das heraus zu abstrahieren oder welche Magie auch immer du brauchst. Ich bin mir nicht sicher, ob ich das die ganze Zeit empfehlen würde, aber es ist möglich es zu benutzen. Die "bessere" Idee wäre, einen DI-Container wie StructureMap zu verwenden und die Entities-Klasse einfach auf den Anforderungskontext zu beschränken, in den Controller einzuspeisen und dann den Lebenszyklus zu erledigen, ohne dass der Controller dies tun muss.