アドバイス

Question

は私の質問ですし、私は彼らのためにあなたの背景をあげる：

• 私はそうです、私のアプリケーションの設計と方法2を使用することを好むだろう方法1のようなフィルタリングを提供し、ビジネス以外のコードへの参照を導入せず、コアプロジェクトのデータベースモデルへのアクセスを許可しない方法がありますか？

• コードの再利用はどのように処理しますか？各オブジェクトの名前空間はProject.Core.DomainまたはProject.Core.Servicesのようなものですが、そのプロジェクトに格納されていない場合はCompanyName.Core.Domainのような名前空間を作成するのは変です。現在、私はソースコードファイルをコピーして名前空間の名前を変更してこれを処理していますが、これを処理するための組織的な方法があるのか​​、それとも考えていないものがあるのでしょうか？

私が使用している技術：

• ASP.NET MVC 3
• LINQのツーSQL
• のStructureMap
• 部品番号
• MSTestを

方法1：

---

は、ここで私はセットアップに私のWebプロジェクトを使用方法は次のとおりです。

データプロジェクトは、すべてのリポジトリ、およびLINQのデータコンテキストを含んでいるでしょう。リポジトリでは、IQueryableを使用してデータベースからオブジェクトのコレクションを返します。

public IQueryable<Document> List() 
{ 
    return from d in db.Documents 
      select d; 
} 

これにより、静的メソッドであるフィルタを設定することができました。これらはデータプロジェクトにも格納されていました。

public static IQueryable<Document> SortByFCDN(this IQueryable<Document> query) 
{ 
    return from d in query 
      orderby d.ID 
      select d; 
} 

サービスレイヤでは、このようにフィルタを適用できます。

public IPagedList<Document> ListByFCDN(int page, IConfiguration configuration) 
{ 
    return repository.List().SortByFCDN().ToPagedList(page, configuration.PageSize, configuration.ShowRange); 
} 

したがって、リポジトリのみのIQueryableオブジェクトとしてすべてのアイテムを返却した後、サービス層は、データのサブセットを返す前にそれをフィルタリングする方法を決定するであろうLISTALL方法を提供しなければなりません。

私はこのアプローチが好きで、サービスのコードの大半を残しながら私のリポジトリをきれいにしました。

方法2

---

ここではどのように現在のセットアップの私のWebプロジェクトです：オニオンアーキテクチャを使用して

：

• コアは：ビジネスドメインモデル、すべてのインターフェイスが含まれていますが、アプリケーションとサービスクラスの実装については、
• インフラストラクチャ：Linqデータベースモデルをビジネスモデルにマッピングするためのリポジトリ実装、Linqデータコンテキスト、およびマッピングクラスが含まれます。

私はビジネスコードをデータベースコードから分離しているので、LinqのようなものにCoreプロジェクトの参照を追加してIQueryableにアクセスしたくないです。そこで、私は、リポジトリ層でフィルタリングを実行し、データベースモデルをドメインモデルにマップしてから、ドメインオブジェクトの集合をサービス層に返さなければなりませんでした。これは私のリポジトリに追加のメソッドを追加する可能性があります。

1）コア事業におけるフィルタリング列挙オブジェクトを作成：

Answer 1

は、これは私がやってしまったものです。 ）インフラプロジェクトの下のリポジトリに

public IPagedList<Document> ListByFCDN(int page) 
    { 
     Dictionary<FilterType, object> filters = new Dictionary<FilterType, object>(); 

     filters.Add(FilterType.SortFCDN, ""); 

     return repository.List(page, filters); 
    } 

3）（：：

public IPagedList<Document> List(int page, Dictionary<FilterType, object> filters) 
    { 
     //Query all documents and map to the model. 
     return (from d in db.DbDocuments 
       select d).Filter(filters).Map(
        page, 
        configuration.Setting("DefaultPageSize", true).ToInt(), 
        configuration.Setting("DefaultShowRange", true).ToInt()); 
    } 

また、コア・プロジェクト内のサービスクラス（）、のような何かを行うには

public enum FilterType 
{ 
    SortFCDN 
} 

2）

4）インフラストラクチャプロジェクトでフィルタクラスを作成します。

public static class DocumentFilters 
{ 
    public static IQueryable<DbDocument> Filter(this IQueryable<DbDocument> source, Dictionary<FilterType, object> filters) 
    { 
     foreach (KeyValuePair<FilterType, object> item in filters) 
     { 
      switch (item.Key) 
      { 
       case FilterType.SortFCDN: 
        source = source.SortFCDN(); 
        break; 
      } 
     } 

     return source; 
    } 

    public static IQueryable<DbDocument> SortFCDN(this IQueryable<DbDocument> source) 
    { 
     return from d in source 
       orderby d.ID 
       select d; 
    } 
} 

サービスレイヤー（コアプロジェクト）は、照会を実行する前に、適用するフィルターを決定し、それらのフィルターをリポジトリー（Infrastructureプロジェクト）に渡すことができます。 FilterTypeごとに1つしか適用されない限り、複数のフィルタを適用できます。

フィルタ辞書には、フィルタのタイプとフィルタに渡す必要のある値/オブジェクトを保持できます。新しいフィルタも簡単に追加できます。