再びGoya

仕事メモ

Goyaって字面を見るとどうしても、ゴヤ、とりわけ『我が子を食らうサトゥルヌス』を思い出す六です。この絵、幼稚園の時好きだったなあ。すげーとか思った。

それはさておき。

はぶさん、お忙しい中、有難う御座居ます！
http://d.hatena.ne.jp/habuakihiro/20060411#1144758729

Serviceクラス

Serviceクラスが受け取るDTOは確かにUIに依存してますが、UI「実装」にはあまり依存しないのではないか、と。POJOのJavaBeansですから。

てな訳で、ServiceクラスはUI「実装」から独立ってのは、OKじゃないでしょうか。うん。

濃いSQLのDTO

ああ、ドメイン層のDTOかー。Dxoでそれをプレゼンテーション層のDTOへ変換する訳でしょうか。そのドメイン層DTOの中身がちょっと気になります。

考えてみる。

くーすの時、例えばS2JSF-Exapmleの従業員管理の場合、DaoのN対1マッピング機能を使わないで、Departmentの名称をプロパティとして持ったDTOを作って、JOINしたSQLを読んで取得してましたね。DTOはEntityを継承して、Departmentの名称を追加した形。で、それをDaoからActionまで使いまわす、と。

  • empno
  • (中略)
  • deptno
  • dname(これをEmployeeDtoで追加)

N対1マッピングを使うより、こっちのが現実的と云うか、作業効率がいい、みたいな判断がありましたね。

で、GoyaになってDxoって考え方が出てきまして、ここが一変したなあと思ったんですよね。SQLを書かずにN対1マッピングで取ってきて、Dxo内で上記の様なDepartmentNameを持ったDTOへ詰め替える、と。

より理想的というか正統的なO/Rマッピングに近づいたなあと思ってわくわくですよ。

それを今回の話に置き換えると。

実際に帳票に表示する項目はこんな感じとして。

  • A：年月
  • B：得意先コード
  • C：得意先名称
  • D：前月売掛金残
  • E：当月入金額
  • F：当月売上金額
  • G：消費税額
  • H：当月売掛金残 (D-E+F+G)
  • I：未決済手形金額
  • J：債権金額 (H+I)

プレゼンテーション層DTOのプロパティはほぼこれと一緒になる訳ですね。

  • 年月
  • 得意先コード
  • 得意先名称
  • 前月売掛金残
  • 当月入金額
  • 当月売上金額
  • 消費税額
  • 未決済手形金額

HやJの導出項目もDTO上にプロパティとして持っちゃってもいいかな、とも思いますがそこはまあどっちでもいいか。取り合えず、表示する際に算定するものとします。getter内で算定でもいいし、jsp上で足し算でもいいし。

ドメイン層のDTOに持つプロパティはこうかな。

  • 年月
  • 前月売掛金残
  • 当月入金額
  • 当月売上金額
  • 消費税額
  • 未決済手形金額
  • 得意先Entityへの参照

で、得意先コードや名称は、得意先EntityをN対1マッピングで取って来て、そこから取得出来る。とか。で、Dxoでプレゼンテーション層のDTOにフラットな形で詰め替え。

あっ、SQLファイルを読み込む場合ってSQL自動生成しないから、N対1マッピングは使えないのか。阿呆だなあ俺。そうするとやっぱりビューを作ってそのビューと対応したEntityみたいな感じでドメイン層DTOを作ってやらんといかんのか・・・・。

ああもう、そこまで凝る必要あるかなあ・・・。ポリシーは筋が通ると云うか一貫するんだけど。ビューにしちゃうとWHERE句をビューの外からしか突っ込めないから重たくならないかも心配。集計ものってそこらへんシビアで、下手打つとすぐ返って来なくなるしなあ・・・。

べき論に耽溺してしまうのもなんだか恥ずかしいのですが、すんごい暇なので今の内に頭を整理しておけば、いざと云う時にダッシュ出来ますので、はい。