Как реализовать принцип СУХОГО при использовании ключевого слова using?

Рассмотрим эти методы:

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

Использование блока такое же и повторялось здесь 3 раза (конечно, более 100 раз в реальном приложении). Как можно реализовать принцип DRY (не повторять себя) для usingблока? Считается ли это нарушением принципа СУХОЙ вообще?

Обновление: я не говорю о том, что было реализовано внутри usingблока. То, что я на самом деле имею в виду, это using (Entities entities = new Entities()). Эта строка повторяется 100 и более раз.

Одна идея заключалась бы в том, чтобы обернуть его функцией, которая принимает Func.

Что-то вроде этого

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

Тогда ваш код выше становится

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

Я также сделал параметр Entitiesтипа, потому что я предполагаю, что у вас есть более одного типа, с которым вы делаете это. Если это не так, вы можете удалить его и просто использовать тип param для возвращаемого типа.

Честно говоря, этот код вообще не помогает читабельности. По моему опыту, все больше Jr коллеги тоже испытывают трудности с этим.

Обновление Некоторые дополнительные варианты помощников, которые вы могли бы рассмотреть

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

Для меня это все равно, что беспокоиться о том, что вы должны несколько раз просматривать одну и ту же коллекцию: это просто то, что вам нужно сделать. Любая попытка абстрагировать его дальше сделает код гораздо менее читабельным.

Похоже, вы путаете принцип «Один раз и только один раз» с принципом СУХОЙ. Принцип СУХОЙ гласит:

Каждая часть знаний должна иметь одно, однозначное, авторитетное представление в системе.

Однако принцип «Один раз и только один раз» немного отличается.

Принцип [СУХОЙ] похож на OnceAndOnlyOnce, но с другой целью. С OnceAndOnlyOnce вам предлагается провести рефакторинг для устранения дублированного кода и функциональности. С DRY вы пытаетесь идентифицировать единый окончательный источник всех знаний, используемых в вашей системе, а затем использовать этот источник для создания соответствующих экземпляров этих знаний (код, документация, тесты и т. Д.).

Принцип СУХОГО обычно используется в контексте реальной логики, а не столько избыточен при использовании операторов:

Сохранять структуру программы DRY сложнее и ниже. Это бизнес-правила, операторы if, математические формулы и метаданные, которые должны появляться только в одном месте. Вещи WET - HTML-страницы, избыточные тестовые данные, запятые и разделители {} - легко игнорируются, поэтому их СУШКА менее важна.

Источник

Я не вижу использования usingздесь:

Как насчет:

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

Или даже лучше, так как я не думаю, что вам нужно каждый раз создавать новый объект.

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

Что касается нарушения DRY: DRY не применяется на этом уровне. На самом деле ни один принцип на самом деле не действует, кроме принципа читабельности. Попытка применить DRY на этом уровне на самом деле является лишь архитектурной микрооптимизацией, которая, как и всякая микрооптимизация, является просто избавлением от велосипеда и не решает никаких проблем, но даже рискует внедрять новые.
Исходя из собственного опыта, я знаю, что если вы попытаетесь уменьшить избыточность кода на этом уровне, вы окажете негативное влияние на качество кода, запутывая то, что было действительно ясным и простым.

Редактировать:
ОК. Таким образом, проблема на самом деле не в использовании выражения, а в зависимости от объекта, который вы создаете каждый раз. Я бы предложил ввести конструктор:

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

Не только использование является дублирующим кодом (кстати, он является дублирующим кодом и фактически сравнивается с оператором try..catch..finally), но и списком toList. Я бы изменил ваш код следующим образом:

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

Поскольку здесь нет никакой бизнес-логики, кроме последней. Это не очень СУХОЙ, на мой взгляд.

У последнего нет СУХОГО в блоке using, но я предполагаю, что предложение where должно измениться, где бы оно ни использовалось.

Это типичная работа для генераторов кода. Напишите и покройте генератор кода и дайте ему сгенерировать для каждого типа.

Поскольку вы создаете и уничтожаете один и тот же одноразовый объект снова и снова, ваш класс сам по себе является хорошим кандидатом для реализации шаблона 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();
    }
}

Это оставляет вам только необходимость использования при создании экземпляра вашего класса. Если вы не хотите, чтобы класс отвечал за удаление объектов, вы можете заставить методы принимать зависимость в качестве аргумента:

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

Мой любимый кусочек непостижимой магии!

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

Wrapсуществует только для того, чтобы абстрагироваться от этой магии или от того, что вам нужно Я не уверен, что рекомендовал бы это все время, но возможно использовать. «Лучшей» идеей было бы использовать DI-контейнер, такой как StructureMap, и просто поместить класс Entities в контекст запроса, внедрить его в контроллер и затем позволить ему позаботиться о жизненном цикле без необходимости в вашем контроллере.