「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回以上）。usingブロックにDRY（Do n't Repeat Yourself）プリンシパルを実装するにはどうすればよいですか？DRYプリンシパルの違反とみなされますか？

更新：usingブロック内に実装されているものについては話していない。ここで私が実際に意味するのは、using (Entities entities = new Entities())です。この行は100回以上繰り返されます。

1つのアイデアは、を受け取る関数でラップすること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あなたがこれをやっている複数の型があると仮定しているので、型パラメータも作成しました。そうでない場合は、それを削除して、戻り値の型に型パラメーターを使用することができます。

正直言って、この種のコードは読みやすさにはまったく役立ちません。私の経験では、より多くの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.

私にとって、これは同じコレクションを何度もforeach-ingすることを心配するようなものです。それはあなたがする必要があることです。さらに抽象化しようとすると、コードの可読性が大幅に低下します。

「一度だけ」の原則とDRYの原則を混同しているようです。DRYの原則は次のとおりです。

すべての知識は、システム内で単一の明確な権威ある表現を持たなければなりません。

ただし、1回限りの原則はわずかに異なります。

[DRY]の原則はOnceAndOnlyOnceに似ていますが、目的が異なります。OnceAndOnlyOnceを使用すると、重複したコードと機能を排除するためにリファクタリングすることをお勧めします。DRYを使用すると、システムで使用されるすべての知識の単一の明確なソースを特定し、そのソースを使用してその知識の適用可能なインスタンス（コード、ドキュメント、テストなど）を生成しようとします。

DRYの原則は通常、実際のロジックのコンテキストで使用され、ステートメントを使用してそれほど冗長ではありません。

プログラムの構造をDRYに保つのは難しく、価値も低くなります。ビジネスルール、ifステートメント、数式、メタデータが1か所にしか表示されません。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クラスを要求コンテキストにスコープし、コントローラーに挿入し、コントローラーを必要とせずにライフサイクルを処理することです。