0

アプリケーションの設計に対する従来の ER ダイアグラム データベース中心のアプローチから来て、OO アプローチを使用してクラスを実装すると、以下の例に示すような混乱が生じます

1) 多対多の関係のクラスを実装します。

次の関係を持つ教授と大学の 2 つのエンティティがあるとします (SO を描画する方法がわかりません。それ以外の場合は、例を図で示したはずです)。

  • 1 人の教授が、講師、客員講師、研究室アシスタント、研究者など、さまざまな能力でさまざまな大学で働く場合があります。
  • 1つの大学には、講師、ゲスト講師、ラボアシスタント、研究員など、さまざまな立場で働く多くの教授がいる場合があります。

これを ER の方法で行うと、次のようなテーブルが得られます

CollegeTable (CollegeId、CollegeName)
ProfessorTable (ProfessorId、ProfessorName))
LecturerTable (LecturerId、CollegeId、ProfessorId、Timings))

したがって、多対多の関係は、エンティティとその他の関係固有のデータの両方の主キーを含むテーブルです。テーブルの行を表すクラスを作成する必要がある場合、それらは次のようになります

class CollegeData
{
    string CollegeId;
    string CollegeName;
}

class ProfessorData
{
    string ProfessorId;
    string ProfessorName;
}

class LecturerData
{
    string CollegeId;
    string ProfessorId;
    DateTime Timings;
}

しかし、OOPで同じことを行い、エンティティをクラスにマッピングすると、次のようになります

class College
{
    string CollegeId;
    string CollegeName;
}

class Professor
{
    string ProfessorId;
    string ProfessorName;
}

class Lecturer
{
    College aCollege;
    Professor aProfessor;
    DateTime Timings;
}

したがって、適切なオブジェクト指向の方法を実行すると、システムにさらに負荷がかかります。これは、ID フィールドだけではなく、多対多クラスで本格的なクラス オブジェクトを作成するためです。タイミングを編集したり、教授を変更したりできる講師の追加/編集ページがあるとしたら、この意味を考慮してください。本格的な教授または大学オブジェクトは必要なく (追加/編集用の独自のマスター ページがあるため)、それらの ID のみが必要です。

2) 1 対 1 の関係のクラスを実装します。

上記の例を拡張して、次の制約を持つ学部長エンティティがあるとします (簡単にするために、学部長は教授ではないと仮定します)

  • 1 つのカレッジには 1 人の学部長を配置でき、1 人が 1 つのカレッジのみで学部長として働くことができます。

再び、私たちが持つERの方法

class DeanData
{
    string DeanId;
    int DeanExp;
}

class CollegeData
{
    string CollegeId;
    string CollegeName;
    string DeanId;
}

、OOPの方法でそれを行いながら

class Dean
{
    string DeanId;
    int DeanExp;    
}

class College
{
    string CollegeId;
    string CollegeName;
    Dean aDean; 
}

また、データを保存またはロードするときに、オブジェクト指向オブジェクトをリレーショナル データベース内のテーブル構造表現にマッピングする際の問題もあります。「冗長性」を持たずに、適切なオブジェクト指向の方法で上記を実行できた方法はありますか? それとも、これは OO の方法で行うことに対して支払われるペナルティですか?

4

2 に答える 2

2

あなたが認識しているように、問題は実際にはあなたが描いているよりも少し悪いです。なぜなら、あなたが呼ぶ「適切なオブジェクト指向の方法」は、実際には1対多の関係の一方の端に逆参照を持つべきだからです。

たとえば、大学講師教授モデルは次のようになります。

class College 
{ 
    string CollegeId; 
    string CollegeName; 
    List<Lecturer> aLecturers;  // <=NOTE THIS
} 

class Professor 
{ 
    string ProfessorId; 
    string ProfessorName;
    List<Lecturer> aLecturers;  // <=NOTE THIS
} 

class Lecturer 
{ 
    College aCollege; 
    Professor aProfessor; 
    DateTime Timings; 
}

データベースに整数の外部キー値のみが含まれる本格的なオブジェクトがある限り、これがオーバーヘッドを作成することを観察したとき、あなたは正しいです。

重要な違いは、DBMS に格納されているすべてのデータをオブジェクト階層に同時にロードする必要がないことです。

コーディングの観点からは、多くの人が ORM フレームワークを使用してオブジェクトの作成を自動化することを好みます。ORM は、適切に設計されたリレーショナル データベースに基づいてオブジェクトを構築するという単調な作業の多くを取り除くことができます。

于 2012-07-11T12:47:00.850 に答える
1

DDD の原則に基づいてモデルを設計することを目指している場合、モデルに双方向の関連付けは必要ありません。

Udi Dahan は、まさにこの主題に関して優れたブログ記事を書いています。ぜひお読みください。

DDD と多対多のオブジェクト リレーショナル マッピング

于 2012-07-11T14:28:32.230 に答える