うわあー - ぶろぐ

うおー！
フロー型の情報をまとめずにうｐするのが好き
最近思ってること、ってか某お仕事で軽い規約みたいなの＋既存のクラス構成的なのが送られてきたので、それを眺めていて思ったこと。

Struts2でModelDriven
を使うときのクラスは、StrutsでいうActionForm的な感じにする
- Strutsやったこと無いから知らないけどなー！
- viewのformから受け取る値を受け取るクラス
- 今までDAOに投げるクラス、DTOとかそういう系にModelDrivenで突っ込んでた⇛微妙かも。ロジック層でmodelオブジェクト⇛dto?entity?に値を詰める処理書こう。（冗長な気もするけどなー！しゃーない）
  - 今までは FooClass implements ModelDriven 的な事してた。
  - class HogeDto { private int id ; private String name; //とあとアクセッサー }
  - これはFormの入力と、Entity?DTO?のフィールドが一対一にならないので微妙
  - FormからはStringで受け取り、後でDate型に変換する、とかやりたいこと多い。ModelDrivenにEntityを使っているとそのままでは入らないので、うみゃぁー…となることが…。メタに勝手に書き換えて入ってくれればいいんだけど…。Struts2だと、外国風で表記されたStringは自動でDate型に変換してくれるみたいだなー。上手くその辺をHackできれば、独自のフォーマットでも自動でInjectionできるようにすることもできるのかも。
  - まずは守ろう。基本は一度Formの値受取り用のmodelオブジェクト⇛ロジック層に渡す⇛Entityに変換処理などして詰める⇛DAOに渡す。

名前のこと

DAO
- だおって読んでおｋ
ValueObject
- 内容が不変
DTO
- DAOとの値の受け渡しに使う。ネストしたBeanを渡すとか。
Entity
- テーブルと一対一。自分の中ではHibernateでDBとMappingされるクラス、ってイメージ。
（ビジネス）ロジック層、サービス層
- serviceとか、logicとかのパッケージに入れる
  - 某所では、
    - Actionクラスは直接DAOを読んではいけない、ServiceクラスがDAOを呼び出すこと。
    - ActionクラスとService層のやり取りは、(ModelDrivenで使う)Modelオブジェクトを使用すること。
  - みたいなこと言ってた（書いてあった）
  - Skinny Controller思想だなーと思った。
  - ActionクラスにUnit Testは回してない雰囲気
  - 全体的にUnit Testは回してない雰囲気だった
  - Service層のテスティビリティ上げていこう！って感じに見えた。
  - あとAction⇛JSPの設定は、アノテーションじゃなくてxmlに書く規約っぽい。ゼロコンフィグレーションは使わないんだなー
  - あ、あとCVS使ってた。Subversionしか使ったこと無いから入門しとかないと。
プレゼンテーション層
- Struts2の層のこと。プレゼンテーション＝表現。

思うこと

もっと腰を据えてやらないとまずいよ。いや、別に大丈夫だけど、腰をすえて学習する期間を置かないと自分の中にスキルが溜まっていかないっぽ。ので、何もしない時間を与えるっていうのは大切だと思うなー! 有効活用できない、と信頼されていないなら悲しい事だ。
もっと社内にナレッジを貯めていくような流れを作ると面白くなると思う!うほ、そんなことやりたかったけど、やる気なくなってる。
同じJava遣いでも、いろんなフレームワークの情報交換したり。
人の頭を使って仕事するようなわけじゃなくて、情報交換をして見える範囲を広げていくような。筋のいい情報源ほしいじゃん。
自分の知っているところは教えるから、そっちの知っている筋の良い情報教えて？と。
インターネット見ていても、不思議と自分の興味がある情報しか入ってこないので他の人の視点をもらう、というのはホント見える範囲広がる。
とかいうことは思っているけど、勉強会には参加したことないという(笑)
現場（客先）ではどうやっているんだろう？

あれ？

ModelDriven使うときのクラスと、DAOに渡すクラスは別々に作る、ということに結構衝撃を受けた、ふわふわとどうしようかなーと悩んでいたのが、これでいこう! と思うきっかけになった、ってことで軽くワクワクしていたんだけど、書いたらどうでも良くなった。
何これ不思議。でも一応ポストしておく