「SpringMVCメモ」の編集履歴（バックアップ）一覧はこちら
SpringMVCメモ - (2006/08/10 (木) 17:01:40) の１つ前との変更点
追加された行は緑色になります。
削除された行は赤色になります。
*Spring MVCのメモ
Spring MVCをmamatumoさん風にメモしてみるテスツ。ただし、千葉が思い出しながら書いてるから嘘の可能性もあり。
*Spring MVCの概要
-ベースはServletとJSPの世界
--ただし、ServletはDispacherServletだけだったり
--JSP以外のビューも視野に入れていたりはする。
-FORMタグのACTION要素にはhoge.htmlとかhoge.formとかなんでもいいから適当に書く。それらがサーバ上に存在する必要は無し。
-適当に書いたhtmlやらformやらのURLパターンはweb.xmlでDispacherServletにマッピングする。
-DispacherServletはさらに、<DispacherServlet名>-servlet.xmlという名前で用意したSpringのアプリケーションコンテキストを見て、URLパターンに適したコントローラクラスに処理を振り分ける。
-ビジネスロジック用クラスはアプリケーションコンテキスト内でコントローラにインジェクション。
-バリデーション用クラスもアプリケーションコンテキスト内で宣言。コントローラの主処理が呼び出される前にDispacherServletが勝手に呼び出す。
-処理結果のフォワードはコントローラの戻り値を元にDispacherServletがよしなにフォワードしてくれる。
-コントローラはインターフェースと、それを実装したものがいくつか容易されており、インターフェースを一から実装するか実装済みのものを目的にあわせて選択し、継承して実装する。
*他のフレームワークとの違いとウリ
**長所っぽいところ
-入力データはJavaBeansの形でコントローラに渡される
--Spring MVC用語では「command」と言うらしい。
-バリデータクラスにも「command」の形で入力データが渡される。
-バリデータクラスは完全にSpring MVCから独立している。
-よって、バリデーションも含め、いわゆるビジネスロジック的なところは「command」さえ渡してやれば、プレゼンテーション層がWebじゃなくなっても動く。多分。
-多分POJO的でテストしやすい。
-仕組み上嫌でもDIコンテナの上で動くので、嫌でもDIコンテナの恩恵が普通に受けられる。
**短所っぽいところ
-コントローラそのものはシグニチャにHttpServletRequestやHttpServletResponseを持っていたり、実用性を考えると何かしらの基底クラスを継承しなければならなかったりと、何かしらへの依存度が強そう。
-バリデータが完全に独立している→組み込みバリデータがちっともなさげ。確かに組み込みバリデータに頼るとWeb層から切り離した場合組み込まれてた分の検証処理は別途実装が必要になってアボンはするが、とはいえバリデーション全部いちいち実装も辛い。
-これはSpring MVCというよりSpringそのもの傾向だけど、やっぱりXMLファイルが肥大する傾向があると思う。
-傾向的にはStrutsが持っていた短所と同じ傾向にあるような気がしないでもない。
*Spring MVCアプリの構成要素
Servletベースのフレームワークで、開発者は下記の要素を作成する。
-web.xml
-アプリケーションコンテキスト
--DispacherServletごとに1ファイルと、共通用のものをもう1ファイル(必須ではないけどあった方が多分便利)。
-JSP
--「Velocity や XSLT などを利用することも可能である」とか[[この辺>http://www.mamezou.com/tec/equip017.htm]]に書いてあるけどどうなんだろね。
-Javaオブジェクト
--最低でも以下のもんは必要
---コントローラ
---バリデータ
--でもMVCを考えると、
---ビジネスロジック
---DAO
--あたりも普通別クラスか。後はデザインパターンによってFacadeだったりなんだったり好きなように。
*Versionの変遷
-現在は1.2系になるのかしら。
-2.0系からはコントローラ内で利用してたModelがHashMapからSpring独自のMapオブジェクトになったりなんやかやあるらしいけどなんやかやあるんだろう、きっと。
*Spring MVCの画面遷移
-基本的に、次の遷移先はコントローラの戻り値にセットし、それを元にDispacherServletが遷移させる。
-コントローラの戻り値は「ModelAndView」という独自の型で、Viewとして次の遷移先を、Modelとしてその遷移先に渡す値をセットする。
--Modelは1.2系ではHashMapで、キーとともにJavaBeansを値としてセットする。
--ViewにはJSP名をセットする。
---/■■■/XXX/△△△.jspというのが遷移先とすれば、△△△のみをコントローラ内でセット。
---/■■■/XXX/はprefix、.jspはsuffixとしてアプリケーションコンテキスト内で設定。
---したりする方法とか、prefixもsuffixも△△△もぜーんぶプロパティファイルに書いといてViewからはプロパティ名だけを指定する方法とか、コントローラ内にフルパスで指定したりとか、まー色々あるらしい。
-JSFのナビゲーションルールよりは設定ファイルに書くこと少ない気がする、多分。
*Spring MVCのFormの扱い
ここにはmamatumoさんは何を書こうとしていたのだろう？
-とりあえず、Formを扱う用のコントローラとしてSimpleFormControllerというのがある。
-1フォームに1コントローラつくイメージ。
--MultiActionControllerというのを使えば複数フォーム扱えるけど、SimpleFormControllerと違って入力データをJavaBeansとして渡してくれなかったり(HttpServletRequestから自分で取得する必要あり)、バリデーションクラスを自動で呼んでくれなかったりと一気に生のServlet色が濃くなるので、たくさん項目があるフォームに対してはあまり実用的でない。
-1フォームの中に複数アクションを持たすのは、JavaScriptとか使って作りこめばまぁまぁ可能そう。
-GET/POSTなどのメソッドは、アプリケーションコンテキスト上で受け付けるかはじくか設定可能(POSTだけ受け付ける、とか)。
-Sessionを持っていないリクエストをはじくのもアプリケーションコンテキスト上の設定で可能。
-基本的にGETメソッドは初回アクセス(初期値表示)用として捕らえているような感じで、GETとPOSTでは同じコントローラでも処理フローが多少違う。
-・・・なんだか何書いてるのか分からなくなってきた。
*Spring MVCの入力検証
-上の方で書いたとおり、
--Spring MVCから独立したバリデーションクラスを用い、
--コントローラの主処理の前にバリデーション実行
--エラーがある場合は、コントローラの主処理をすっとばして元ページのタグで指定した場所にエラーメッセージを表示
-するっていうのは、まぁそんなに特異な処理ではないと思う。単項目検証や入力項目間の整合性検証はこれでうまくいくけど、EIS層のデータとの間での整合性検証が問題。
-思想的にバリデーションはバリデーションクラスで完結し、ビジネスロジックに持ち込ませないような思想を見受けるので、
--バリデーションクラスで単項目検証・入力項目間の整合性検証→コントローラ→ビジネスロジック→入力項目・EIS層のデータ間の整合性検証とやると、エラーを元の画面に返すのに何かしら工夫する必要がありそう。
---エラーページに飛ばすなら簡単だけど。
--流れ的には、バリデーションクラスからDAOを呼んで(Facadeとかを間に挟んでもいいけど)バリデーション用のデータを取得し、バリデーションクラス内で入力項目・EIS層のデータ間の整合性検証をやってバリデーションをここで完結させるのが自然ぽいけど、1リクエスト内でバリデーションとメインのビジネスロジック別々にデータベースアクセスするのもなんか美しくない。
---プーリング機能を使えば処理負荷はそうかからんだろうけども。
-・・・なんだか何書いてるのか分からなくなってきた。
*Spring MVCのメモ
Spring MVCをmamatumoさん風にメモしてみるテスツ。ただし、千葉が思い出しながら書いてるから嘘の可能性もあり。
*Spring MVCの概要
-ベースはServletとJSPの世界
--ただし、ServletはDispacherServletだけだったり
--JSP以外のビューも視野に入れていたりはする。
-FORMタグのACTION要素にはhoge.htmlとかhoge.formとかなんでもいいから適当に書く。それらがサーバ上に存在する必要は無し。
-適当に書いたhtmlやらformやらのURLパターンはweb.xmlでDispacherServletにマッピングする。
-DispacherServletはさらに、<DispacherServlet名>-servlet.xmlという名前で用意したSpringのアプリケーションコンテキストを見て、URLパターンに適したコントローラクラスに処理を振り分ける。
-ビジネスロジック用クラスはアプリケーションコンテキスト内でコントローラにインジェクション。
-バリデーション用クラスもアプリケーションコンテキスト内で宣言。コントローラの主処理が呼び出される前にDispacherServletが勝手に呼び出す。
-処理結果のフォワードはコントローラの戻り値を元にDispacherServletがよしなにフォワードしてくれる。
-コントローラはインターフェースと、それを実装したものがいくつか容易されており、インターフェースを一から実装するか実装済みのものを目的にあわせて選択し、継承して実装する。
*他のフレームワークとの違いとウリ
**長所っぽいところ
-入力データはJavaBeansの形でコントローラに渡される
--Spring MVC用語では「command」と言うらしい。
-バリデータクラスにも「command」の形で入力データが渡される。
-バリデータクラスは完全にSpring MVCから独立している。
-よって、バリデーションも含め、いわゆるビジネスロジック的なところは「command」さえ渡してやれば、プレゼンテーション層がWebじゃなくなっても動く。多分。
-多分POJO的でテストしやすい。
-仕組み上嫌でもDIコンテナの上で動くので、嫌でもDIコンテナの恩恵が普通に受けられる。
**短所っぽいところ
-コントローラそのものはシグニチャにHttpServletRequestやHttpServletResponseを持っていたり、実用性を考えると何かしらの基底クラスを継承しなければならなかったりと、何かしらへの依存度が強そう。
-バリデータが完全に独立している→組み込みバリデータがちっともなさげ。確かに組み込みバリデータに頼るとWeb層から切り離した場合組み込まれてた分の検証処理は別途実装が必要になってアボンはするが、とはいえバリデーション全部いちいち実装も辛い。
-これはSpring MVCというよりSpringそのもの傾向だけど、やっぱりXMLファイルが肥大する傾向があると思う。
-傾向的にはStrutsが持っていた短所と同じ傾向にあるような気がしないでもない。
*Spring MVCアプリの構成要素
Servletベースのフレームワークで、開発者は下記の要素を作成する。
-web.xml
-アプリケーションコンテキスト
--DispacherServletごとに1ファイルと、共通用のものをもう1ファイル(必須ではないけどあった方が多分便利)。
-JSP
--「Velocity や XSLT などを利用することも可能である」とか[[この辺>http://www.mamezou.com/tec/equip017.htm]]に書いてあるけどどうなんだろね。
-Javaオブジェクト
--最低でも以下のもんは必要
---コントローラ
---バリデータ
--でもMVCを考えると、
---ビジネスロジック
---DAO
--あたりも普通別クラスか。後はデザインパターンによってFacadeだったりなんだったり好きなように。
*Versionの変遷
-現在は1.2系になるのかしら。
-2.0系からはコントローラ内で利用してたModelがHashMapからSpring独自のMapオブジェクトになったりなんやかやあるらしいけどなんやかやあるんだろう、きっと。
*Spring MVCの画面遷移
-基本的に、次の遷移先はコントローラの戻り値にセットし、それを元にDispacherServletが遷移させる。
-コントローラの戻り値は「ModelAndView」という独自の型で、Viewとして次の遷移先を、Modelとしてその遷移先に渡す値をセットする。
--Modelは1.2系ではHashMapで、キーとともにJavaBeansを値としてセットする。
--ViewにはJSP名をセットする。
---/■■■/XXX/△△△.jspというのが遷移先とすれば、△△△のみをコントローラ内でセット。
---/■■■/XXX/はprefix、.jspはsuffixとしてアプリケーションコンテキスト内で設定。
---したりする方法とか、prefixもsuffixも△△△もぜーんぶプロパティファイルに書いといてViewからはプロパティ名だけを指定する方法とか、コントローラ内にフルパスで指定したりとか、まー色々あるらしい。
-JSFのナビゲーションルールよりは設定ファイルに書くこと少ない気がする、多分。
*Spring MVCのFormの扱い
ここにはmamatumoさんは何を書こうとしていたのだろう？
-とりあえず、Formを扱う用のコントローラとしてSimpleFormControllerというのがあって、普通はこれを継承する。
--なんや、StrutsのActionFormみたいなもんか？といわれるとそうかもしれないがStrutsには手を付けていないので実際のところ知らん。
-1フォームに1コントローラつくイメージ。
--MultiActionControllerというのを使えば複数フォーム扱えるけど、SimpleFormControllerと違って入力データをJavaBeansとして渡してくれなかったり(HttpServletRequestから自分で取得する必要あり)、バリデーションクラスを自動で呼んでくれなかったりと一気に生のServlet色が濃くなるので、たくさん項目があるフォームに対してはあまり実用的でない。
-1フォームの中に複数アクションを持たすのは、JavaScriptとか使って作りこめばまぁまぁ可能そう。
-GET/POSTなどのメソッドは、アプリケーションコンテキスト上で受け付けるかはじくか設定可能(POSTだけ受け付ける、とか)。
-Sessionを持っていないリクエストをはじくのもアプリケーションコンテキスト上の設定で可能。
-基本的にGETメソッドは初回アクセス(初期値表示)用として捕らえているような感じで、GETとPOSTでは同じコントローラでも処理フローが多少違う。
-・・・なんだか何書いてるのか分からなくなってきた。
*Spring MVCの入力検証
-上の方で書いたとおり、
--Spring MVCから独立したバリデーションクラスを用い、
--コントローラの主処理の前にバリデーション実行
--エラーがある場合は、コントローラの主処理をすっとばして元ページのタグで指定した場所にエラーメッセージを表示
-するっていうのは、まぁそんなに特異な処理ではないと思う。単項目検証や入力項目間の整合性検証はこれでうまくいくけど、EIS層のデータとの間での整合性検証が問題。
-思想的にバリデーションはバリデーションクラスで完結し、ビジネスロジックに持ち込ませないような思想を見受けるので、
--バリデーションクラスで単項目検証・入力項目間の整合性検証→コントローラ→ビジネスロジック→入力項目・EIS層のデータ間の整合性検証とやると、エラーを元の画面に返すのに何かしら工夫する必要がありそう。
---エラーページに飛ばすなら簡単だけど。
--流れ的には、バリデーションクラスからDAOを呼んで(Facadeとかを間に挟んでもいいけど)バリデーション用のデータを取得し、バリデーションクラス内で入力項目・EIS層のデータ間の整合性検証をやってバリデーションをここで完結させるのが自然ぽいけど、1リクエスト内でバリデーションとメインのビジネスロジック別々にデータベースアクセスするのもなんか美しくない。
---プーリング機能を使えば処理負荷はそうかからんだろうけども。
-・・・なんだか何書いてるのか分からなくなってきた。
