使用“ using”关键字时如何实现DRY原理？

考虑以下方法：

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次以上。

一种想法是将其包装为带有的函数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了类型参数，因为我假设您要使用多个类型。如果不是，则可以将其删除，而只需将type 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.

对我来说，这就像担心多次遍历同一集合：这只是您需要做的事情。任何进一步对其进行抽象的尝试都会使代码的可读性大大降低。

听起来您好像将“一次且只有一次”原理与DRY原理混淆了。DRY原则指出：

每条知识都必须在系统中具有单一，明确，权威的表示形式。

但是，一次和唯一一次原理稍有不同。

[DRY]原理类似于OnceAndOnlyOnce，但目标不同。鼓励您使用OnceAndOnlyOnce进行重构，以消除重复的代码和功能。使用DRY，您尝试确定系统中使用的每条知识的唯一权威来源，然后使用该来源生成该知识的适用实例（代码，文档，测试等）。

DRY原理通常在实际逻辑的上下文中使用，而使用using语句并没有那么多冗余：

保持程序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实际上只是架构上的微优化，就像所有微优化一样，它只是丢车而已，并没有解决任何问题，甚至存在引入新问题的风险。
根据我自己的经验，我知道如果您尝试在该级别上减少代码冗余，则会混淆真正清晰和简单的内容，从而对代码质量产生负面影响。

编辑：
好的。因此，问题实际上不是using语句，而是问题是每次都依赖于您创建的对象。我建议注入一个构造函数：

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块中没有任何DRY，但我猜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存在只是为了将其抽象出来或您需要的任何魔法。我不确定我会一直建议这样做，但是可以使用。“更好”的想法是使用像StructureMap这样的DI容器，并将Entities类的作用域限定在请求上下文中，将其注入到控制器中，然后让它处理生命周期，而无需您的控制器。