複数テーブルが存在するアプリにおけるDTOの設計について

Question

複数テーブルが存在し、かつ複数テーブル感でリレーションのある場合に、DTOやDAOをどのように設計すべきか悩んでおります。以下、5テーブルがあるとします。

id
name
maker_id
size_id

id
size (S,M,L)

id
name

id
customer_id
item_id
quantity

上記5テーブルに対し、現状makerとitemのDTOがあります。

public class MakerDto {
  private String name;
  // getter, setter
}

public class ItemDto {
  private String name;
  private MakerDto maker;
  private // SizeDto size ?  int sizeID ?
  // getter, setter
}

ここで疑問に思ったのですが、サイズテーブルもDTO化すべきでしょうか？
DTO化するとなると、テーブル全てをDTO化することになり、テーブルの数だけDTOができてしまうので、現状は問題ないですがいずれ膨大な数になってしまうと思います。
しかしアプリケーションの中でサイズを使いたいとなれば、IDだけ持ってても、また検索が必要になるのでそれもないよな...とも思っております。

このような場合、どのようなアプローチが適切なのでしょうか。

Answer 1

DTO化するとなると、テーブル全てをDTO化することになり、テーブルの数だけDTOができてしまう

これについては特に問題ありません。

理由として大量に増えたとしても業務ドメインや機能がわかれる＝パッケージが分離するものですし、IDEを利用して検索やクラスを辿って表示も可能なので、正しくグループ分けができればさほど気になりません。

Answer 2

汎用的なDTOは持っておいても構わないかと思いますが、そこは要件次第。
別のテーブルのために同じDTOを共有するのはあまりよろしくないと思います。
まずは設計を確定されてはどうでしょうか。
あまり共有しすぎると、仕様変更に弱い作りになるのではと言う懸念はあります。
依存しすぎも良くないですが、汎用しすぎも良くはないです。
ただ、それもアプリケーション自体の目的にもよるので、
やはり、もっと全体と今後のことを考えた上で設計し、データの持ち方を考えるべきと思います。

Comments

[potato_taro]

ご回答いただきありがとうございます。
＞別のテーブルのために同じDTOを共有するのはあまりよろしくない
というのは、私の例で挙げたItemDtoがMakerDtoを持つような事例のことでしょうか？

[m.ts10806]

いえ、リレーションがあるのなら、むしろ持っておいた方が良いですし、その例は「共有」ではなく「保有」です。
私が意図しているのは「汎用的なDTO」のことです。
例えば「CommonDto」のような名前で「id . name」だけ持っておくとかそういうもののことです。