0

次のドメイン モデルがあるとします。

Project                Task
    - Id                   - Id
    - Name                 - Name
    - List<Task>           - Project

プロジェクトには多くのタスクがあり、タスクには 1 つのプロジェクトがあります。

ここで、TodoListDTO データ転送オブジェクトを作成するとします。私の当初の考えは、これを行うことでした：

TodoListDTO
    - List<Project>

シンプルに見えます。次に、各プロジェクト内のタスクのリストにアクセスできます。次に、DTO は可能な限りフラットにする必要があるといくつかの場所で読みました。しかし、複雑なオブジェクトを使用せずにそれをモデル化するにはどうすればよいでしょうか?

TodoListDTO の代わりに、次のような ProjectDTO を使用できます。

ProjectDTO
    - ProjectId
    - Name
    - List<TaskId>
    - List<TaskName>

しかし、TaskIds と TaskNames の個別のリストを持つことは不便に思えます。ProjectDTO に List プロパティを持つことよりも、それがどのように優れているかはわかりません。

これを処理する良い方法は何ですか?

4

2 に答える 2

4

もう 1 つできることは、別のドメイン モデルを作成することです。

ProjectTask
    - ProjectId
    - ProjectName
    - TaskId
    - TaskName

これは、1 対多の関係 (多対多も可能) に役立ち、紛らわしい循環的なプロジェクト -> タスク -> プロジェクト -> タスク構造を回避するのに役立ちます。ここから、API クライアントにすべての ProjectTask を projectId でグループ化し、その方法で処理させることができます。

そうは言っても、元の方法で問題ないと思いますが、別の方法があります。

于 2016-08-26T23:18:46.733 に答える
1

以前のクラスは十分に単純で、標準的な方法でした。プロジェクトとタスクのリストを保持する Context クラスを作成します。全3クラス。

于 2016-08-26T22:39:25.003 に答える