0

このプロジェクトでは主に DDD の方法論に従ってきたので、他の DDD 担当者と同様に、最初にドメイン モデル クラスを作成しました。私の意図は、これらの POCO を LINQ-to-SQL エンティティとして使用することです (はい、純粋な POCO ではありませんが、それで問題ありません)。データベース スキーマと外部マッピング XML ファイルの作成を開始しましたが、エンティティの関係と関連付けをモデル化する際に問題が発生しています。

アーティファクトはドキュメントを表します。成果物は、タスクまたはケースのいずれかに関連付けることができます。Case エンティティは次のようになります。

public class Case 
{
     private EntitySet<Artifact> _Artifacts;
     public IList<Artifact> Artifacts
     {
          get
          {
               return _Artifacts;
          }
          set
          {
               _Artifacts.Assign(value);
          }
     }
     .
     .
     .
}

Artifact は Case または Task のいずれかに関連付けることができるため、Artifact クラスで継承を使用して CaseArtifact および TaskArtifact 派生クラスを作成するオプションがあります。ただし、2 つのクラスの唯一の違いは、ケース フィールドまたはタスク フィールドの存在です。もちろん、データベースには、タイプ識別子フィールドと CaseId および TaskId フィールドを持つ 1 つのテーブル Artifact があります。

私の質問: これはこの問題を解決するための有効なアプローチですか、それとも関連付けごとに結合テーブル (合計 2 つの新しいテーブル) を作成するのがより良いアプローチでしょうか?

4

2 に答える 2

2

私はおそらく2つのテーブルを使用します-参照整合性を作成します-セレクタ列に基づいて複雑な制約を設定する必要がないため、データベースでのPK/FKの処理が少し簡単になります。

（コメントに返信するには-スペースが足りなくなったので、編集としてここに投稿してください）私の全体的な哲学は、データベースをデータベースのベストプラクティスでモデル化する必要があることです（可能な限り多くのRIと制約を使用して、境界を保護し、データベースの整合性を確保します） 、SPを介したすべてのアクセスを提供し、必要に応じてアクティビティをログに記録し、すべてのアクセスモードを制御し、必要に応じてトリガーを使用します）。オブジェクトモデルは、強力で一貫性のあるAPIを提供するためにOOPのベストプラクティスでモデル化する必要があります。インピーダンスの不一致を処理するのは、SP/データアクセス層の仕事です。

適切に設計されたオブジェクトモデルをデータベースに永続化するだけの場合、オブジェクトモデルのレンズを使わずに表示した場合、データベースには本質的な価値があまりありません（データマイニング、レポート、ウェアハウス、メタデータのあいまいさなど）。これは一部のアプリケーションでは問題ありませんが、通常は私のアプリケーションでは問題ありません。

豊富なOOAPIを提供せずに、アプリケーションで適切に設計されたデータベース構造を模倣した場合、アプリケーションの保守が困難になり、内部構造の処理が困難になります。通常、非常に手続き型で、厳密で、多くのコードが含まれます。複製。

于 2009-11-16T19:23:43.477 に答える
1

caseとtaskの間に共通点を見つけることを検討します。より適切な言葉がないため、「CaseTask」と呼び、そこからサブタイピング (継承) します。その後、ドキュメントをスーパータイプに添付します。

更新（コメント後）：
次に、このようなことを検討します。各ドキュメントは、複数のケースまたはタスクに添付できます。



artifact_model_01D

于 2009-11-16T20:09:10.220 に答える