私はこの質問を書き直すと思いました（同じ繰り返し）。元は、EAV/CRデータベースの周りにリポジトリパターンをラップする方法でした。私は別のアプローチを試みています。"factory"デザインパターンのようなリポジトリパターンをどのようにコーディングしますか？
質問：データ・リポジトリを「工場」設計パターンでコーディングするにはどうすればよいですか？私は固定数のエンティティを持っていますが、これらのエンティティの属性はかなり顧客固有のものです。彼らはすべて類似している商品を宣伝しますが、各顧客はビジネスモデルに基づいて異なる情報を顧客に付けます。たとえば、一部の人は廃棄物の割合を気にし、他の人は売却したポンドの量を気にします。別の顧客が見つかるたびに、一連のフィールドを追加し、一連のフィールドを削除し、各ソリューションを最新の一般リリースに最新の状態に保ちます。
リポジトリクラスをファクトリパターンにすることができると思ったので、顧客タイプが分かったら、どのフィールドを使うのか分かりました。実用的？もっといい方法？ Webフォームでは、レイアウト上のフィールドを反映するように変更されたユーザーコントロールが使用されます。現在、レイアウトにあるフィールドを商品テーブルの項目に「結合」してから、CRUD一般項目を選択します。
前の質問内容：
私たちは、同じエンティティの異なるクラスを可能にEAV/CRデータモデルを持っています。これは、顧客が大きく異なる製品を持っている製品を追跡します。顧客は製品の「クラス」を定義し、フィールドをロードしてデータを入力することができます。例えば、
Product.Text_Fields.Name
Product.Text_Fields.VitaminEContent
この周りのリポジトリパターンをラップする方法上の任意の提案？
私たちは3つのテーブルEAVを持っています：Productテーブル、Valueテーブル、フィールド名とデータタイプをリストするメタテーブル（Product.PriceやProduct.Price Metaデータ、Product.Photoなど）。顧客は、競合他社の割引率やフライ計算など、あらゆる種類の価格を追跡します。
現在、LinqにはC＃でSQLを使用しています。
編集：
私は、以下の "動的クエリー" LINQのが好き。私たちのDBの背後にあるアイデアは、ロッカールームのロッカーストレージのようなものです。各選手（または顧客）は、自分の希望する方法で自分のロッカーを構成し、そのために保管します。私たちは、ロッカーに必要なことをできる限り、ロッカーに何があるか気にしません。
非常に興味深い...リポジトリに渡されたオブジェクトは動的である可能性がありますか？これは、工場パターンのようにほとんど意味があります。顧客が独自のクラス定義をテキストファイルに入れて、継承してDBに格納することは可能でしょうか？