vieweditattachhistoryswikistopchangessearchhelp

JavaServlet

Java で、サーバーサイドのプログラムを構築するための、下地となるプログラム単位
(とすべきものとして(Sunによって？)位置付けられてる)であるクラス。

それ自体は、「要求(Request)」を寄越されたら「返答(Response)」を返す、というプログラムモデルであり、
そういう処理をするメソッド1つを、自分が望む処理でオーバーライドすれば、
おおまかに言えば、やる(やれる)ことはそれでおしまいである。

オブジェクト指向っぽさは希薄。
Servletは星の数ほど有るであろうサーバーサイド用アーキテクチャのうちの1つをサポートしてるだけであり、
しかもそれはCGIっぽい非オブジェクト指向的な(入力→処理→出力という)アーキテクチャである。

ましてや、(無理矢理そんなコーディングしない限り)Servlet自体が
特定のオブジェクトを体現(=Model??)したりするわけではないし、
特定のオブジェクトの世間とのお付き合いを制御(=Controller)するわけでもない。

というわけで、こういうクラス自体をMVCの要素であるかのように呼ぶのは、
羊頭狗肉というかなんというか、間違いであるような気しか、(俺には)しない。

Servlet自体は、MVC(もし作りたいならば)の、足回りの更に足回り(笑)くらいの
非常に低レベルな位置付けのものだろう。
実際、JSPやその他の多くの上位(?)技術の土台になってる。

なおJSPは、内部的にServletクラスを直接継承して作られるクラスなので、
ServletのMVCからの遠さと同じくらいに、JSPもまたMVCから遠い、と思う。
MVC(のView?)の下地の下地だ。
--戯

こんなプログラムモデルなのだが、上記のオーバーライドされるメソッドは
クラスメソッドではなくインスタンスメソッドである。
つまりJavaServletは、状態を持たない(ことが期待される)のに、インスタンスをわざわざ作るのである。
(作る行為自体はServletエンジンが自動的にやってくれる、とはいえ…)
どうにも恰好悪い。
Javaの限界(笑)のせいだろう。特に「クラスメソッドが(わざわざrefrection APIを明示的に呼ばない限り)多態できない」せいだろう。

一方、いわゆるオブジェクトらしいオブジェクトの座は、
「Request」や「Response」、あるいは
ユーザがサーバにコンニチワしてる単位である「Session」、
などといったオブジェクトである。
あるいはそれらに束縛しておく(ユーザ任意の)オブジェクト。

つまり、Servlet「が」世界(MVC、特にModel)を持っているわけではない。
Servlet自体はあくまで、要求に応じて一瞬の処理を受け持つだけだ。

この「ユーザ任意」の部分に色々なオブジェクトを乗っけることで、
Servlet上に構築された各種技術は、MVC(あるいはモドキ)を実装することになる。
ModelやViewやControllerを乗っけようとするフレームワークが色々有る。
--戯

Servletでは、要求とかがHttpに根ざしているかどうかは別問題。

Servletの標準装備の子クラスとして、 Httpを捌くように仕込まれたHttpServletというクラスがあり、
それを使えばプログラムはHttp対応版だ、というわけだ。

まあ、実際には、こんな風にあたかも「お気軽にPluggableに差し替え可能」であるかのような誤解(笑)を
招く文を書いてしまうと、大嘘なのだが。

そこまで柔軟ではない。
--戯

このページを編集 (2677 bytes)

Congratulations! 以下の 1 ページから参照されています。

This page has been visited 8517 times.