Linq式の基本クラスを変換する

Question

私は分離されたドメインモデルを構築しようとしています。私の（抽象的な）ドメインモデルはエンティティ（例えばProduct）を定義し、具体的なSQL実装はそのドメインエンティティへの変換メソッドを提供します。

例えば：

public interface IDomainEntity<T> where T : class 
{ 
    T ToDomainEntity(); 
} 

私の具体的なSQLクラスは、そのインターフェイスを実装：私の製品ドメインサービスから

public partial class Product : IDomainEntity<Domain.Product> 
{ 
    public Domain.Product ToDomainEntity() 
    { 
     return new Domain.Product 
     { 
      ProductId = this.ProductId, 
      ... 
     }; 
    } 
} 

を、私は一般的なフィルタ法

を公開できるようにしたいです

public virtual IQueryable<T> Filter(Expression<Func<T, bool>> predicate) 
{ 
    return GetAll().Where(predicate); 
} 

この場合、TはDomain.Productタイプです。私が持っている問題は、SQLリポジトリの実装では、式をDomain.Product型からSql.Product型に変換する必要があるため、Linq to Sqlテーブルに対して使用できることです。これは理にかなっていない場合は、事前に

Expression<Func<Domain.Product, bool>> 

Expression<Func<Sql.Product, bool>> 

に謝罪：

は、それが一つの発現基盤を取り、別のに変換することが可能です。

Answer 1

あなたがしたいことが可能であっても、実際の質問は次のようにする必要があります：これを行うことによって何かが得られるでしょうか？

私の意見では、Filterメソッドは既に大きな1つです。漏洩抽象です。フィルタ入力が式であるのはなぜですか？なぜそれは単なる「普通の」デリゲートではないのですか？私の心に唯一の答えは、述語を現在のフォームからオブジェクト指向ではない別のものにマッピングするために式が必要なためです。

したがって、ヒーロー的な努力にもかかわらず、APIは引き続き基本的な実装がリレーショナルであることを意図していることを裏付けています。言い換えれば、結局はそれほどデカップルされていません。

さらに、the IQueryable return type is also problematic for similar reasonsの使用。

Answer 2

これは興味深い問題です。 predicateが式ではなくファンクタだった場合、変換は簡単ですが、生成したSQLに式を渡すことはありません。

Sql.ProductとDomain.Productが共通のインターフェイスを持っていれば、それを使うことができますが、私はあなたがそのようにしたくないという質問から集まります。

私は、「あなたはそれをすることはできません」、または2.「表現の木を歩いて自分で翻訳しなければならない」と信じています。あなたに実用的であるかもしれません。