Як реалізувати принцип DRY при використанні ключового слова "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блоку? Чи взагалі це вважається порушенням принципу DRY?

Оновлення: я не говорю про те, що було реалізовано всередині usingблоку. Що я тут фактично маю на увазі, це using (Entities entities = new Entities()). Цей рядок повторюється 100 і більше разів.

Однією з ідей було б обернути її функцією, яка виконує функції a 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парам типу, тому що я припускаю, що ти маєш більше одного типу. Якщо цього немає, ви можете вийняти його та просто використати параметр типу для типу повернення.

Якщо чесно, хоча такий тип коду зовсім не допомагає читати. На моєму досвіді, більше молодших колег теж дуже важко проводять час з цим.

Оновіть кілька додаткових варіантів помічників, які ви можете розглянути

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

Мені це було б як турбуватися про пророкування про одну і ту ж колекцію кілька разів: це просто щось, що вам потрібно зробити. Будь-яка спроба її абстрактно надалі зробить код менш читабельним.

Здається, що ви плутаєте принцип "Раз і тільки раз" з принципом DRY. Принцип DRY визначає:

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

Однак принцип "Один і єдиний раз" дещо інший.

Принцип [DRY] схожий на OnceAndOnlyOnce, але з іншою метою. Завдяки OnceAndOnlyOnce вам пропонується зробити рефактор, щоб усунути дублюваний код та функціональні можливості. За допомогою DRY ви намагаєтеся визначити єдине, остаточне джерело кожного знання, що використовується у вашій системі, а потім використовувати це джерело для створення застосовних примірників цього знання (код, документація, тести тощо).

Принцип DRY зазвичай використовується в контексті фактичної логіки, не настільки зайвої, використовуючи заяви:

Зберігати структуру програми DRY важче та менше. Це бізнес-правила, заяви if, математичні формули та метадані, які мають з’являтися лише в одному місці. Власні речі - 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));
}

Оскільки тут немає жодної ділової логіки, окрім останньої. На мій погляд, це насправді НЕ СУХО.

Останній не має жодного DRY у використанні блоку, але я здогадуюсь, де пункт повинен змінитися там, де він використовувався.

Це типова робота для генераторів коду. Напишіть і вкрийте генератор коду і нехай він генерується для кожного типу.

Оскільки ви створюєте та знищуєте один і той же одноразовий об’єкт знову і знову, ваш клас є самим хорошим кандидатом для реалізації шаблону 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 до контексту запиту, ввести його в контролер, а потім дозволити йому піклуватися про життєвий цикл, не вимагаючи від цього контролера.