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