複雑なオブジェクトモデルのリポジトリパターンを実装するにはどうすればよいですか？
私たちのデータモデルには約200のクラスがあり、約12の機能領域に分けることができます。ドメインを使用することは良かったでしょうが、分離はそれほどクリーンではなく、変更することはできません。
Entity Frameworkを使用するようにDALを再設計し、 私が見たほとんどの推奨事項 がリポジトリパターンの使用を提案しています。ただし、どのサンプルも実際には複雑なオブジェクトモデルを扱っていません。私が見つけたいくつかの実装は、エンティティごとのリポジトリの使用を提案しています。これは、大規模で複雑なモデルの場合、ばかげて維持できないようです。
オペレーションごとにUnitOfWorkを作成し、エンティティごとにリポジトリを作成する必要がありますか？何千ものクラスになる可能性があります。これが不合理であることはわかっていますが、複雑なモデルや現実的なビジネスアプリケーションに対してリポジトリ、作業単位、エンティティフレームワークを実装するガイダンスはほとんど見つかりませんでした。
最初に、あなたが持っているすべてのエンティティを実行し、自分自身に尋ねます：
このエンティティのみを永続化することは理にかなっていますか？
ここで私が意味するのは、オブジェクトモデルでは、一部のエンティティが主従関係で他のエンティティに含まれている可能性が高いということです。エンティティが別のエンティティに強く依存している場合は、このエンティティだけでは永続化されない可能性があるため、このエンティティのみのリポジトリを作成しないでください。代わりに、各親クラスのリポジトリを作成し、子エンティティと他の関係が同時に永続化されるようにします。
あなたが提供したリンクにUnitOfWorkパターンをどのように実装したのか私は好きではありません。私はあなたにもっと何かをすることをお勧めします これらの行に沿って 。リポジトリごとに1つのクラスを定義する必要はありません。同じクラスをすべてのリポジトリに使用できます。各リポジトリには、操作の存続期間中、UnitOfWorkクラスの独自のインスタンスがあります。同じUnitOfWorkを異なるリポジトリで再利用して、同時に永続化したい変更を行うこともできます。
多分あなたは Domain-Driven Design を見るべきです。オブジェクトを集合体にグループ化し、各集合体のルートエンティティに対してのみリポジトリを作成することをお勧めします。これは、大きな複雑なオブジェクトモデルに秩序をもたらす良い方法です。
あなたのさまざまな機能領域は Bounded Contexts です。 さまざまな手法 があり、それらの間の分離が明確でない場合に、重複する境界コンテキストを処理します。
「リポジトリパターン」のデータベース設計について、どのような理論的基盤を見つけましたか？誰もいないと思います。これは、偽の前提に基づく複雑さの層です。「持続性層」は、分離する必要があるものです。私が言うことができることから、それはリレーショナルデザインの原則の広範なプログラミングの無知に影響を与え、アプリケーションのOOデザインの前提とされた中心性に行き着きます。しかし、それは合理的、理論的にのみ、根拠。
データベース設計への1つの真の道は30年経っても変わっていません。データを分析することです。キーと制約、および多対1の関係を見つけます。ボイス-コッドの通常の形式に従ってテーブルを設計します。ビューとストアドプロシージャを使用して、データアクセスを容易にします。
好まれないかもしれませんが、SQL DBMSは、プログラマーが提供できるものよりも優れた分離レイヤーを提供します。データベースが変更されると、データベースへのアクセスに使用されるSQLも変更される可能性があることは事実です。ただし、これは真実であることに注意してくださいメディエーションレイヤーの有無に関係なく。アプリケーションがビューとストアドプロシージャを使用してDBMSにアクセスしている限り、通常のSQLエンジニアリングツールは、基になるデータベースへの変更がこれらのビューとストアドプロシージャを無効にするタイミングを示します。
もちろんそこに課題があります。メディエーションレイヤーは、プログラマーに分離の錯覚と快適さを提供し、プログラマーはコードの作成方法を知っています。データベース設計とSQLを学ぶには、何か新しいことを学ぶ必要があります。ほとんどの人は考えるよりもむしろ死にたいと思い、多くは成功します。
あなたのチームの誰かが、200クラスをサポートするSQLを書くのは大変な仕事だと異論を唱えるでしょう。間違いない。しかし、少なくとも便利の作業です。 OO設計を模倣してデータベースを設計する場合、多くの作業が無駄になり、DBMSが提供するほとんどの機能が無効になります。
たとえば、データベースに作業単位を反映することを検討しているとします（テーブルまたはテーブルとして）。 作業単位は、DBMSの組み込みサービスです：begin transaction ... データベースを更新する ... commit transaction。 SQLのデータベーステーブルへのクラスのマッピング以外に、モデル化するものはありません。
あなたの質問は4年前に投稿されました。最近何らかの形で「更新」されたので、私は答えています。私の回答が読者に、無意味な回避策を採用する代わりに、基本的な関係理論を問題に適用することを奨励することを願っています。