<< ドメインオブジェクトの粒度 : テーブルとのマッピング | main | 朽ちていくD51 >>

ドメインオブジェクトの粒度 : XML とのマッピング

小さなオブジェクト

このモデルを XML ドキュメントにマッピングすると、1ファイル。

<employee id="4822" >
ここにオブジェクトをツリー上に並べていく
</employee>

基本的に、システム間のデータ送信に使うので、一回の送信単位としては、こんな感じでしょう。

インタフェース用のオブジェクト

XML ドキュメントは、基本は、画面の単位と同じと思っている。

ユーザとのインタフェースが、画面。
システム間のインタフェースが、XML。

こういうインタフェースの粒度は、大きな単位にまとめるのが普通ですね。

画面やXMLに限らず、RMI やデータアクセスでも、小さなオブジェクトを、DTO ( Data Transfer Object ) という入れ物にまとめて、大きな単位で処理する。

JAR や WAR も、考え方としては同じですね。
小さなオブジェクトの集まりを移動して配置するために、扱いやすいように、大きな単位にまとめる

Java < テーブル < XML

結局、同じモデルを実装する粒度は、

Java : とても小さく分割 (7 つのクラス)
テーブル : まとめる (2つのテーブル)
XML : 1つにまとめる

という違いがでてくる。

UML のクラス図との比較で言えば、私の場合は、UML のクラスアイコン数より、Java のクラスの方が多い。

例えば、上の図だと、Money オブジェクトを、アイコンとして記述しているけど、クラス図では、普通は、ここまで書かない。給与オブジェクトの中で表現しておしまい。

String が登場するたびに、クラス図に String をクラスアイコンとして書いていたのでは、仕事になりませんからね。 作業が面倒というより、図にノイズが増えて、モデルの本質がどこかにいっちゃうから。


コメント
コメントする









この記事のトラックバックURL
トラックバック
UMLによるJavaオブジェクト設計
UMLによるJavaオブジェクト設計 継承を使うのはごく限られた場合だけで,あるクラスの機能を拡張するには普通コンポジションを使...
  • もぼなもな書房
  • 2009/05/22 5:06 PM
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM