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