日々の破片

_ action-logic-data

s2jsfをいろいろ見てるんだが、actionとlogicの役割を分ける必要って実際のところあるんだろうか？ と激しく疑問。

StrutsのActionや、Sun J2EEパターンのJSP Type2の例に出てくるコマンドの場合、Actionはとっても中途半端な役割を持つのだが、なんでそれが中途半端かと言えば、手元のネタが生なHttpServletRequestか、せいぜいActionForm程度だからだ。

ところが、s2jsfだと全然違う。（と書いて気付くと、JSFのマネージドビーンに相当するんだっけ？）

全然違うというとそれなりに嘘が混じっていてメソッドは無引数、戻り値String制限とかがある。でもJSFのマネージドビーンもそうだけど、似たような縛りでもStrutsのActionなんかとは異なるのは、ドキュメントモデルを中に持てる点だ(後、完全なPOJOという点。Servlet APIにもStruts.jarにも依存しない)。ドキュメントモデルと（そんな必要はないけど）データモデルが対応できる場合には、完全な支配者にだってなれる。特にS2JSFのActionの場合、DI思いのままだし。

JSFの場合は、名前がマネージドビーンで、ビーンはビーンだからビーンとして扱えば良いのだけど、S2JSFはサンプルとかでActionと名前を付けているし、そこからロジックみたいな名前のものを呼ぶことになっている。これって、Strutsからの単なる類推じゃないのだろうか？ 最初からビーンとして（ロジックがんがん。データアクセスは切り分けたほうが良いと思うけど、それは別の話だし、実際問題いくらでも切り分けられる）で行けば良いと思うのだが、なんでこうしているんだろう？

#ページごとに独立させる場合、ロジックのシェアが奇妙な感じになる（感じだけなら良いけど、担当者を分離する場合には不利だな）とかだろうか。

#ああ、そうか。JSFを利用するとJSP Type1とほぼ同じアーキテクチャになるんだな。だからJSPに直接ビーンが植えられていても違和感がない（にもかかわらずJSPにはロジックは埋め込まれない、基本的に。ロジックを埋め込んだタグは埋め込まれるけど）。だからJSP Type2流儀のMVCではなく、よりシンプルなUI−bean（イベントドリブン）−データアクセスで、デスクトップGUIアプリケーションに近いアーキテクチャを取る（ことができる）。あとは、その「ことができる」が自然なのか、ことはできるがそうしないほうが良いが自然なのか、という問題のように思える。（で、Actionいらないな、と感じる僕は、「ことができるんだから、そうしたほうが良い」と考えているということのようだ）

つまるところ、ASP.NET（V1.1）だ。

#追記：ロジックはシングルトンという方針がある、あるいは他のフレームワークにもロジックは流用させたいという希望、の2点かも。ビーンはリクエスト単位に1インスタンスだし、そうすると他のフレームワークのロジックモジュールとしては流用できない。

#追記の追記：と書いたら、少なくともその点（リクエストにつき1インスタンスと、アプリケーションのエクステント（って言葉で合ってるかな？ 寿命のこと）で1インスタンス）については合っているらしい。

#層としては（上のインスタンス化単位については置いておくとして）、プレゼンテーションと考えなくても良いと思う。それは上にも書いたけど僕にはアーキテクチャとしてJSP Type2ではなく、デスクトップモデルと同じほうが直観的ではないかと考えているからだけど、それは

プレゼンテーション（JSP+JSFコントロールで、成果物はHTML）−DTO(成果物はJavaクラス）−ロジック（ビーン−S2JSFのActionはここと考える。成果物はJavaのインターフェイスとクラス）−DTO（Javaのクラス）−データアクセス（S2Daoを使うならJavaのインターフェイス、Javaのクラスでももちろん良い）

とビーンをプレゼンテーション層に位置づけるのではなく、プレゼンテーション層とデータ層の中間層としたほうが誰にでもわかりやすいのではないかというところ。特に、なんだかいっぱいファイルを作らなくちゃならなくて面倒ですなぁ、というような人に対して、単なるデリゲートが目に見えては出てこない分だけ良いのではないかと思う。

#ただ、イベント発生でプロパティをいろいろ設定してからメソッド呼んで何かさせるという形式は、プレゼンテーション層のビーン（あるいはOCXとかVBX）の振る舞いそのものじゃん、と言われれば、それは確かにその通りなので、そこはちょっと弱いな。

#Actionとロジックを分離する理由は納得。インスタンス化の単位の問題と他のフレームワークへのロジックの可搬性は遙かに高い（Action−S2JSFの−は純粋なPOJOだけど、外部インターフェイスがプレゼンテーションのイベントドリブン処理を実行するのに向いている形式であって、いわゆるプロシージャを提供するロジックとは異なる、それをもってプレゼンテーション層のモジュールと見なす）、という2点。

_ 田中哲さんのどういうAPIが良いAPIか資料

リンクを貼ってもdeFlateされるんじゃな、と思ったけど、されないようなので。

open-uri, Easy-to-Use and Extensible Virtual File System。

クラスを作ってもメソッド名とかがクラスそれぞれだとおいしくないと思っているだけに、参考になる。