えっと、生きてますよ。
blog書いてないのは、単にネタがないだけであります。
普通に土日は休んでますし、忙しいわけではないのです。
バイクに乗る意欲が、トンと沸かないのが不思議でしょうがないんですがね。
さて。
せっかくJavaの研修を終えて、いざ開発！と意気込んでいたんですが、実は途中で研修は離脱してます。
なんでかというと、別のデケェ開発が始まるのでそれに合流するためです。
そんなわけで、連休明けのサーバーチューニングの研修も延期しております。
で、その開発がSOAなんですが、いやぁ、これがさっぱり分からんわけですよ。
オブジェクト指向とはまた違ったもので、同じようなものと考えていると痛い目を見る、とよく言われています。
SOAの厄介なところは、ネットに情報が転がってないんですよね。
Javaなんかは個人でも結構ガリガリできますが、SOAになるとある程度の、いや、かなりデカイ規模のシステムで、さらに数多くにシステムが連携している場合でないと、事例もないわけです。
さらに、その開発環境やサーバーはI○Mやら、○racle（伏字になってない…）だったりして、個人でどーのこーのできんじゃない。
まぁ、OSSでも構築できんこたぁないんでしょうけど。
SOAを理解する前に、Webサービスそのものの理解をしておく必要がある事が、今回よーく分かりました。
今までなんとなくしか理解してなかったので、ここんところは結構楽しく勉強できました。
一旦はAxis2を使って、Webサービスの仕組みを勉強したのですが、いやぁ、よくできてますね。
WSDLがあれば、スタブを自動生成できたりとか、すげぇなーって思いました。
ただ、Webサービスの難しいところもなんとなく感じました。
連携元のサービスが連携先のサービスを利用しようとした際、これまでだと連携先の仕様を十分に理解する必要があったりするわけです。
Webサービスの考え方でいうと、各々が疎であり、WSDLが全てを握っているので、相手先の事を理解しなくてもお互いのサービス連携が容易にはなるのです。
がしかし、疎であるがゆえに、相手先の事を無視した作り方もできてしまうのです。
あと、エンジニアとしては、相手先がどういう仕組みで動くのかがよくわからないまま、こちらの仕組みを組み立てるというのは、気持ちが悪いものです。
なんともいえないモヤモヤ感が残りっぱなしで、フラストレーションがたまり、不安なんですよね。
この辺りを、どう納得感を得ながら取り組んでいくかで、出来上がるものが違ってくると思うのです。
今回、自部門から参加するメンバーは自分を入れて５人で、5年目前後の若手中心。
自分は間にブランクがあるものの10年になるので、立ち振る舞い方も考えながらであります。
この開発で終わりではなく、次の開発につなげる必要があり、メンバーで技術習得に加えて、自部門での開発メンバーへの引き継ぎができる状態でノウハウを持ち帰るするのが大きなミッションでもあります。
始まって２週間弱ですが、成果物が出せるだけではなく、技術者として納得感のある取り組み方ができるようにすることこそ、今回の大きな役割であると認識しました。
8月末までは、この開発にどっぷりつかれそうです。
なんとか最終課題の提出とプレゼンが終わりました。
合否判定はずっと先ですが…。
とりあえずこれで講師への技術質問が解禁になったので、気になってた事を軽く整理してもらいました。
まず、図というか、こんな感じで層を分けるとします。
Actionクラス ｜ ビジネスロジックのクラス ｜ DAO ｜ DB
Actionクラスから左側は書いてませんがStrutsです。
今の段階ではビジネスロジックをActionクラスに書いてます。
上記の図に従うと、Actionクラスがビジネスロジックに依存しない形で実装する事になります。
同様に、ビジネスロジックとDAOも依存関係がないようにします。
こうすることで、フロント側に変更がかかった場合、つまり、Strutsじゃなくなった時でも手が打ちやすい。
同様に、DB周りが変わった場合は、DAOクラスに手を入れるだけでよい事になります。
なるほど、なるほど。
で、ここで登場するのが、各クラス間のオブジェクトのやりとり、つまりデータのやりとりをするためのオブジェクトが必要です。
その型にあたるものがEntity（ValueObject）、DTO。
型というと漠然としていますが、DB等からSELECTしてくると、複数レコード取得したりします。
この時の１レコード分のデータを詰めるものがDTO。
DTOには、DBからSELECTしてくる項目を定義している感じです。
複数レコード取得してくる場合は、Listにぶち込むわけですな。
一方で、Entity（VO）は、Actionとビジネスロジックの間でやりとりされるもので、セッションやリクエストスコープに詰めるもの、と考えるようです。
Action <=> ビジネスロジック ： Entity(VO)
DAO <=> DB ： DTO
あれ、「ビジネスロジック <=> DAO」は何だっけ？？？
まぁ、あれだ。
より生データに近いものは、表示するために遠いデータ。
たとえば金額とかだったらint型でDBに入ってるので、DTOにはint型で入ってる。
これを表示するために近い形で持つEntityでは、金額のフォーマット（￥999,999）とかで、Stringで入ってたりするのかな。
このあたりの変換や計算をするのはビジネスロジックに任せる。
Actionクラスは結局ビジネスロジックが処理した結果を元に、画面遷移やスコープに詰めるだけって事だね。
ひーこら言いながら取り組んだ課題だったけど、ここまでの考え方を理解した瞬間、作り直したい感が満載でした
まぁ、今の知識ではActionクラスとビジネスロジックとの依存関係を断ち切る事ができないのも分かったんですけどね。
これを解決するために、DIコンテナのお話が出てくるようなんで、またお勉強です。
今時点では、Actionクラスのexecute()内には
コレクション型<何某> hehe ＝ new コレクション型<何某>（）；
ビジネスロジック型 hoge ＝ new ビジネスロジック型（）；
hehe = hoge.getFuga()；
if( hehe == null){
mapping.エラーページ
}else{
httpsession.setAttribute(”HEHE”,hehe)；
mapping.正解のページ
}
みたいな事をするのが精いっぱいですかな。
結局今日は、Actionにベタ書きしていたSQL部分を切り出して、DAOに分離させるっぽい事にチャレンジ。
まず、抽象クラスとして、コネクションをはるところ、executeQuery()、executeUpdate()、ロールバック、コネクションやステートメントのクローズを準備。
準備といっても、Google先生に教えてもらったサイトからちょいと拝借してカスタマイズ。
で。
ここから先は、どういう単位で継承クラスを準備するか。
この部分は、いろいろ議論が及ぶところですが、正直まだよく分かんない。。。
Entity単位に準備すれば良さそう、というのはなんとなくわかります。
ていうか、そもそもEntityってどういう単位として考えるか。
が、勘違いしてはいけないのが、画面＝Entityではないということ。
そして、TABLE＝Entityでもないということ。
と、今は考えています。
きっと似たような問い合わせをする画面が複数あったりするわけですよ。
画面単位で用意すると、似たようなSQL文があちこちのDAOに散らばる事になります。
今思いついた事ですが、ある程度汎用的な問いあわせ…つまり、AというテーブルとBというテーブルを結合したCというViewっぽいものを、全カラム取り出すEntityをざっくりと用意します、と。
これを、必要に応じて各Actionから利用する。
これなら、Aというテーブルのa、bのカラムを利用するAction、ａ,cのカラムを利用するActionがあるとすると、同じEntityとみる事が出来ます。
テーブルが複数になっても、Viewとしてみれば問題ないでしょう。
で、今日は結局Actionから分離させる、DAOの抽象クラスを作って、分離させた部分を継承クラスへ実装する、にとどまりました。
つまり、DAOの継承クラスの中に全部放り込んじゃいました（汗
まぁ、アプリケーションの規模によってはこういうのもありじゃないかと思いますが、ソースコードが500行近くになってきたので、そろそろ分割した方がいいかと思う今日この頃であります。
—————-
さて、もうひとつ未解決があります。
例外クラスのExceptionとSQLExceptionを、それぞれをそれぞれの独自例外を用いてActionクラスでcatchさせるには…？
単純に考えたのが、Actionクラスのexecute()内を全てtry～catchで囲ってやって、SQLException→Exceptionの順にcatchしてや…。。。。
あれ、なんかおかしくないかな？
SQLExceptionは、基本的にはDAOクラスで発生するので、DAOクラスでcatchしたら、独自例外にスローする。
DAOを利用しているActionクラスでは、独自例外をcatchして画面遷移に利用できます。
どっこい、Exceptionはあちこちで発生…というか、全ての検査例外の親クラスなのでActionクラスで発生したExceptionで独自例外に渡してやるっっていっても、Actionクラスからはどこにスローするの？？？
スローできたとして、何が処理するの？
んー、tomcatかしら。
struts-configに、global-exceptionを定義できるので、Exceptionをcatchして独自例外がスローしたものは、こいつがひらってくれるのか。
でも、Exceptionよりも先に発生したSQLExceptionは、スローさせてきた結果、親クラスであるExceptionに持っていかれちゃったりしないのか。
DAO、独自例外、いずれももう少し試してみるだけの時間もなく時間切れになりそうだなぁ。
毎度、オブジェクト指向にどっぷりな生活を過ごしています。
先週後半から、最終課題に突入しています。
一応、習得内容から実装するのですが…講義の内容と課題の内容がぶっ飛んでます。
１、２教えたから、残りの９は自分で考える、もしくはGoogle先生によろしく！なんていう状況です。
しかも最終課題中は、技術的な質問や周りの人との相談もNGなんですよね。
まぁ、こういう自力でしんどい思いをするからこそつく力もあるんでしょうけども。
で、つい先ほど力尽きて帰宅したのですが。
実装できてないのがDAO。
Strutsを使ってますが、現状Actionに直接SQL書いちゃってます。
考え方そのものは理解できるのですが、実用アプリ実装レベルになると、手が止まるんです。
DAOの作成単位とか、いまいちピンとこないのです。
そもそも研修内で触れてないところだし！
それってどーなん！？
さて。
極端な話、SELECTのDAO、UPDATE、DELETEのDAOの２つだけでもいいのか？
ステートメントを渡して、excuteQuesry()か、executeUpdate()のどっちかを実行するだけ。
あぁ、これじゃだめだ。
たとえば、極端な話特殊なDBに変更になった場合や、テキストファイルなんかになったら改修箇所大杉。
DAOFactoryみたいなクラスを作って、問い合わせ単位でアクセサメソッド作る方がいいか。
問い合わせ、更新、削除対象となるオブジェクトの参照値を渡してやる。
問い合わせの場合は、戻り値は要考慮。
DAOクラスでSQLExceptionが発生した場合はどうなるのか。
他の参加メンバーが、FilterでSQLExceptionをcatchしてやろうとしていました。
どっこい、ActionクラスからSQLExceptionをスローしても、いろいろ経路を通ってくる間に、ServletExceptionとかExceptionになってしまうとの事。
上位層のビジネスロジックにまでスローしないようにするには、独自例外を作ってそいつにスローするって事になるわけですか。
なるほど。
それで課題の中に「SQLExceptionを継承した独自例外を作る事」ってーのがあるんだな。
ていうか、明日しかないんですが。
現状動いているので、手を入れたくないんだよなぁ。
データアクセスって結構肝じゃないか。
プレゼン直前に動かなくなるって、ありえねーしなぁ。
ってか、考えるなら会社でやれっつーの。
帰ってきて服脱ぎ散らかしたまま、布団に寝そべってノートPCつついてググってるわけで。
まぁ自宅だからリラックスして頭が回るってのもあるんだけどね。
なんていうか、もう一日だけ余分に納得いくもの作れそうなんだけどなぁ。
まぁ、Strutsも枯れた（熟成された）フレームワークなんだけど、決して効率のいいものじゃないってことは分かったかな。
前回、研修の課題に行き詰まったお話を書いたんですが。
その翌朝、なんだか身体に異変が。
あれ、左耳が聞こえない…！？
いや、聞こえるんだけど、聞こえにくい。
なんていうか、耳が遠いっていうか、泳いだ後耳に水が入ってるような感じでして。
一日とりあえず様子をみる事にしたんですが、音がこもって聞こえるので、ちょっとした物音とか全然聞こえなくてですね。
まぁ、この日は丸一日課題に取り組む日だったので、講義もなくて、かえって集中できたような気もしますが。
さすがに放置はまずいだろうと思って、翌日起きて変わってなかったら病院だ…。
って思ってたら、翌日って病院休みじゃん(汗
というわけで、夜遅い時間でしたが耳鼻科へ行ってきました。
で、診察始まって５秒くらいでしたかね。
お医者さん「あぁ、中耳炎ですね」って。
原因はっきりして一安心だったわけですよ。
ていうかですね」、中耳炎って子供がなるもんだって思ってたんですけどね。
大人のなってから中耳炎ってあんまり聞かないじゃないですか。
まぁそれはいいとして。
中耳炎って、鼓膜の内側に水がたまっている状態なわけですよね。
これが化膿してたりすると、発熱したり痛みを伴ったりするようです。
僕の場合は熱や痛みはなくて軽い症状のようです。
ええ、研修では課題が手詰まり。
体調では耳が詰まってる状態です。
次は何が詰まるんでしょうか。
2010年7月18日 23:56 | 
