は、私がインターフェイスを持っていた始めたときに多くの方法

Question

を使用してデータアクセスのデザインについての右感じていませんこのアプローチは成長し続けるでしょう。私はより多くの異なった質問が必要です。次に、私は次のようなインターフェースを持っていました：

public struct FindCriteria 
{ 
    DateTime? from; 
    string category; 
    string author; 
} 

public interface IBlogReader 
{ 
    BlogPost GetLatest(); 
    IEnumerable<BlogPost> Find(FindCriteria criteria); 
} 

インターフェイスが小さくなり、多くの方法を控えることができました。しかし、私は基本的に、多くのメソッドの実装を大きなホントな単一メソッドの実装に移しました。それはしばらくの間、気分が良くなった。

public abstract class QueryCommand 
{ 
    protected IBlogReader reader = null; 
    public QueryCommand(IBlogReader reader) 
    { 
     this.reader = reader; 
    } 

    public abstract void Execute(); 
} 

public class GetLatest : QueryCommand 
{ 
    public BlogPost GetResults(); 
    public void Execute(); 
} 

public class FindByDate : QueryCommand 
{ 
    public IEnumerable<BlogPost> GetResults(); 
    public void Execute(); 
} 

それはまだ右感じていない：私は、各オブジェクトは、詳細を取り扱い、私は結果を求める個々のオブジェクトのシリーズにビッグ鳴らしqueryメソッドを包んアプローチへの移行を考えていました。私はリポジトリのパターンについて読んでいて、それがどのように適用されるかわかりません。私はまだ最後に多くの方法で終わるだろうと私には思われました。データはクラウドに格納されています。仕様パターンを使用することは、それを読むことがすべての記録を資格にローカルに持ち込むほど重すぎることになります。別の試みで、私は個々のDAOオブジェクトを作成し、それらをリポジトリのようなファサードオブジェクトの内部にラップしました。最終的な結果は、私が始めたものと同じでした...多くの方法...しかし、リポジトリはすべての作業をしませんでした。

私は多くの方法や多くのオブジェクトのいずれかを持っていて、それを乗り越えるべきだと思いますか？

Answer 1

Query Objectのように見えます。 時には我々はまた、それのバリエーションを使用します。

public class Filter 
{ 
    public DateTime? PostDate { get; set; } 
    public DateTime? LastComment { get; set; } 
    public string Author { get; set; } 
} 

をそして表現をフィルタリングするnull以外の基準を解決します。

Answer 2

IQueryable<BlogPost>を公開してみませんか？あなたが説明する問題は、このアプローチが理にかなっている理由です。ここで

は変更され、あなたのインタフェースです：

public interface IBlogReader 
{ 
    IQueryable<BlogPost> Posts { get; } 
} 

次に、あなただけのクエリを実行できますように

IBlogReader myReader = new MyReader(); 
var latest = myReader.Posts.Last(); 
var posts = myReader.Posts.Where(x => x.Author == "John Smith"); 

をと。

LINQ to SQL、Entity Framework、またはNHibernateなど、このアプリケーションをサポートするデータアクセスソリューションが既に多数存在することに注意してください。