Jak wdrożyć zasadę DRY przy użyciu słowa kluczowego „using”?

Rozważ te metody:

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

Korzystanie z bloku jest takie samo i zostało tutaj powtórzone 3 razy (oczywiście ponad 100 razy w prawdziwej aplikacji). Jak można zaimplementować zasadę DRY (Don't Repeat Yourself) dla usingbloku? Czy w ogóle uważa się to za naruszenie zasady DRY?

Aktualizacja: Nie mówię o tym, co zostało zaimplementowane w usingbloku. Chodzi mi o to, że using (Entities entities = new Entities()). Ta linia jest powtarzana 100 razy lub więcej.

Jednym z pomysłów byłoby owijanie go funkcją, która wymaga Func.

Coś takiego

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

Wtedy twój powyższy kod staje się

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

Zrobiłem Entitiesteż param typu, ponieważ zakładam, że masz więcej niż jeden typ, z którym to robisz. Jeśli nie, możesz go usunąć i po prostu użyć parametru type dla typu zwracanego.

Szczerze mówiąc, ten rodzaj kodu wcale nie poprawia czytelności. Z mojego doświadczenia wynika, że ​​bardziej współpracownicy Jr również mają z tym naprawdę ciężki czas.

Aktualizacja Niektóre dodatkowe odmiany pomocników, które możesz rozważyć

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

Dla mnie byłoby to tak, jakby martwić się o wielokrotne przepowiadanie tej samej kolekcji: to po prostu coś, co musisz zrobić. Jakakolwiek próba jego dalszego wyodrębnienia spowodowałaby, że kod byłby mniej czytelny.

Wygląda na to, że mylisz zasadę „Raz i tylko raz” z zasadą OSUSZANIA. Zasada DRY stanowi:

Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie.

Jednak zasada „raz i tylko raz” jest nieco inna.

Zasada [DRY] jest podobna do OnceAndOnlyOnce, ale ma inny cel. Dzięki OnceAndOnlyOnce zachęca się do refaktoryzacji w celu wyeliminowania powielonego kodu i funkcjonalności. Za pomocą DRY próbujesz zidentyfikować pojedyncze, ostateczne źródło każdej wiedzy wykorzystanej w twoim systemie, a następnie użyć tego źródła do wygenerowania odpowiednich instancji tej wiedzy (kod, dokumentacja, testy itp.).

Zasada DRY jest zwykle stosowana w kontekście rzeczywistej logiki, nie jest zbyteczna przy użyciu instrukcji:

Utrzymanie struktury programu DRY jest trudniejsze i ma niższą wartość. To reguły biznesowe, instrukcje if, formuły matematyczne i metadane powinny pojawiać się tylko w jednym miejscu. Rzeczy WET - strony HTML, nadmiarowe dane testowe, przecinki i ograniczniki {} - łatwo można zignorować, więc SUSZENIE ich jest mniej ważne.

Źródło

Nie widzę zastosowania usingtutaj:

Co powiesz na:

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

Lub nawet lepiej, ponieważ nie sądzę, że musisz za każdym razem tworzyć nowy obiekt.

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

Jeśli chodzi o naruszenie DRY: DRY nie ma zastosowania na tym poziomie. W rzeczywistości żadna zasada tak naprawdę nie działa, z wyjątkiem zasady czytelności. Próba zastosowania DRY na tym poziomie jest tak naprawdę tylko mikrooptymalizacją architektoniczną, która podobnie jak każda mikrooptymalizacja jest po prostu zrzucaniem rowerów i nie rozwiązuje żadnych problemów, ale nawet grozi wprowadzeniem nowych.
Z własnego doświadczenia wiem, że jeśli spróbujesz zmniejszyć nadmiarowość kodu na tym poziomie, wywrzesz negatywny wpływ na jakość kodu, zaciemniając to, co było naprawdę jasne i proste.

Edycja:
Ok. Tak więc problemem nie jest tak naprawdę instrukcja using, problemem jest zależność od obiektu, który tworzysz za każdym razem. Sugerowałbym wstrzyknięcie konstruktora:

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

Nie tylko używanie jest duplikatem kodu (tak na marginesie, jest duplikatem kodu i faktycznie porównuje się z instrukcją try..catch..finally), ale także toList. Zmienilbym kod twojego kodu w ten sposób:

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

Ponieważ nie ma tutaj żadnej logiki biznesowej z wyjątkiem ostatniej. Moim zdaniem nie jest to naprawdę SUCHE.

Ten ostatni nie zawiera DRY w bloku używającym, ale myślę, że klauzula where powinna się zmienić tam, gdzie kiedykolwiek była używana.

Jest to typowe zadanie generatorów kodu. Napisz i zakryj generator kodu i pozwól mu generować dla każdego typu.

Ponieważ ciągle tworzysz i niszczysz ten sam obiekt jednorazowy, twoja klasa sama jest dobrym kandydatem do wdrożenia wzorca 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();
    }
}

To pozostawia tylko „używanie” podczas tworzenia instancji klasy. Jeśli nie chcesz, aby klasa była odpowiedzialna za usuwanie obiektów, możesz sprawić, że metody zaakceptują zależność jako 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();
}

Moja ulubiona odrobina niezrozumiałej magii!

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

Wrapistnieje tylko po to, aby wyodrębnić tę magię lub inną potrzebną magię. Nie jestem pewien, czy poleciłbym to przez cały czas, ale można z niego korzystać. „Lepszym” pomysłem byłoby użycie kontenera DI, takiego jak StructureMap, i po prostu objęcie klasy Entities kontekstem żądania, wstrzyknięcie go do kontrolera, a następnie pozwolenie mu zająć się cyklem życia bez konieczności kontrolera.