【Struts2とは？】初歩の初歩をイメージでつかむ【第1章】
プログラマカレッジ学習記録。
Struts2って何なの！という超基本的な問題にタックルします。
Struts2を使ってログイン認証機能を作るとき、一番最初の演習を写経した時はとりあえず動作するものは完成したものの実際に何がどうなって結果が表示されているかはよくわからない状況に陥ってしまいました。
あちこちネット上やらYoutubeやらを漁った結果、ざっくりと分かってきたのでここで噛み砕いてまとめてみます。
まずこの記事が１章目で、２章構成となっています。
- １章目でStruts2とは何か？を最低限ざっくり図解する
- ２章目で具体的なStruts2のコードレベルで図解する
こんな感じでいきます。
※スマホからだと絵が小さくて読みにくいかもしれません
本記事を読むと分かること
- 「Struts2とはMVCモデルのフレームワークである」の意味が分かるようになる
厳密な理解を求める記事ではありませんので悪しからず。
「何か色々なファイルを作って書き写してきたけど、なにがなんだか分からん」という状態から、「ん？・・・あ〜・・・まぁ、M・V・Cってのがあるってのは分かった・・・かな？」という状態を目指します。
MVCが分かれば、他言語でフレームワークを勉強する時に楽です。将来、「あぁ、Struts2でMVCやったからなんとなく分かるわ！」と気づく時が必ず来ます。楽しみにしましょう。
Struts2とは何か？
いきなり核心に迫る質問です。Struts2とは何なのか？
どうやらどのサイトを調べても必ず出てくる文言は、
Struts2とは「MVCモデル」を採用したJavaの「フレームワーク」
ということらしいです。・・・よく分からんですね。
ここで新たに２つの疑問が生まれてしまいました。
でも「Struts2とは何か」という漠然とした疑問よりは１段階具体的な疑問に落とし込めましたね。
Struts2を理解するには
- MVCモデルってなに？
- フレームワークってなに？
この２つの疑問をざっくり理解できればよさそう。
それでは、以降では「Struts2とは何か？」の答えを知るために
「MVCモデルとは何か？」
「フレームワークとは何か？」
についてそれぞれ順番に考えていきましょう。
MVCモデルとは何か？
まず「MVCモデル」から。これは、
- Model (モデル)
- View (ビュー)
- Controller (コントローラ)
の３つの頭文字を取った略だというのは聞いたことがある方はいるかもしれません。聞いたことがない人も安心してください。
まず、これらはそれぞれ「役割」を表しています。
モデルは「モデルという役割」
ビューは「ビューという役割」
コントローラは「コントローラという役割」
を持ちます。OKでしょうか？
MVCモデルは、M・V・Cという３つの役割を示しています。
モデル・ビュー・コントローラが「具体的に」どんな役割を意味するかは後で説明するので今は無視して大丈夫です
そして、
モデルはモデル役専用のファイルに。
ビューはビュー役専用のファイルに。
コントローラはコントローラ役専用のファイルに。
役割ごとに別々のファイルに分けてプログラミングコードを書いていきましょう。
と捉えておく程度にしましょう。
「役割ごとに別々に分ける」というのがキーです。
モデル役のファイルにビューとして動作するコードは一切書きません。
ビュー役のファイルにコントローラとして動作するコードは一切書きません。
コントローラ役のファイルにモデルとして動作するコードは一切書きません。
ここまでをいったん軽くまとめます。
MVCモデルとは、
- モデル・ビュー・コントローラという３つの役割を示しており、
- その役割ごとにファイルを別々に分けて管理する
こんなイメージです。
プログラミングのように曖昧で物理的に触ることができないものは、可能な限り具体的なイメージとして頭に浮かべることが非常に大事です。
なので、MVCモデルという言葉を見たら聞いたら、このように「役割ごとにファイルが３分割されている図」を頭に思い浮かべてください。
・・・ちなみにもうひとつ、「モデルは処理役、モデルは処理役、モデルは処理役、モデルは処理役」と今は無心で頭に焼き付けてこの先を読んでください。
なぜかというと、View と Controller は英単語そのままの見た目で役割の想像ができるんですけど、Modelってどう頑張っても最初はイケメンか美女のファッションモデルのような想像をしてしまうんですよね(僕だけ？)。
プログラミング的にはモデルは処理役です！！
処理というのは「登録処理」「検索処理」「削除処理」「ログイン判定処理」等、文字通り受けとった値に対して何らかの作用を与えるということです。
準備はOKでしょうか？モデルは処理役ですよ。イケメン美女は全く関係ないです。
MVCとは具体的に何を意味するのか？図解してみる
とあるこんなシチュエーションがあるとします。
「僕が「Strutsって何やねん」とGoogle検索窓に入力してググる」
この検索窓に入力された文字列が、検索結果として目の前の画面に返ってくるところまでのコンピュータ内部の動きを「MVCモデル」の働きに沿って考えるとどうなるか、を考えてみます。
イメージしやすくなるよう、コードが書かれたファイルを軽く擬人化します。
以下ググる動きを例にしますが、もちろんGoogle検索がStruts2で動いているわけではありません。もしMVCモデルの動きだったとしたらこんな感じ、という僕の例え話です
↓まず、あなたがパソコンのブラウザ上の検索ボタンをポチッとおして検索処理をかけた以下の瞬間をイメージしてください。
※図中の「Googleのサーバ」といった表現はあくまでも簡単にするための例です
頭の中でイメージしましたか？
かならず、クリックしたらインターネットを超えて存在しているサーバに依頼が届くようなイメージを頭の中で映像を思い浮かべてください。それが学習効率を上げるコツです。
↓クリックすると、サーバ側で待ち受けているファイルが検索依頼が来たことに気付いて受け取ります。
「この文字列で検索してくれ」という依頼内容を判断し、検索処理役の別のファイルへと検索入力内容をポイっと渡してそのファイルに検索処理を指示します。
検索依頼を一番最初に受け取った関西弁のファイル自身が検索処理をすることはなく「ユーザから来た依頼を見て、実際の処理は担当者(別ファイル)へ丸投げ指示するだけ」というのがポイントです。
なぜ、受け取ったファイル自身が検索処理をしないのでしょう？受け取ったんだから、そのファイル自身で検索処理までやればいいのに。
・・・
ここで、MVCモデルの考え方が登場します。
MVCモデルの基本的考えは「役割ごとにコードを書くファイルを別々に分ける」と数十行前に書いたのを覚えているでしょうか。
図中の一番最初の関西弁ファイルは、ユーザからの検索依頼を「受け取ったら、偉そうにあれやれこれやれと指示を出す」という役割だけを持っています。
別の役割(その後の検索処理)を関西弁ファイルが担ってしまうと、それはもうMVCモデルではありません。
ここまでOKですか？ では次のフェーズです。
↓「検索処理担当」のファイルが「Strutsって何やねん」という入力情報を受け取りました。このファイルは、受け取った情報(「Struts2について調べろ」という依頼)を元にデータベースへ検索処理をし結果を受け取ります。
↓検索処理が終わった頃合いを見計らって、今度はまた一番最初の関西弁ファイルが再登場し、また別の「処理結果をパソコン画面に返す役割のファイル」へと「結果をユーザ画面に返してや」と指示します。
ここも、あくまでも指示をするだけです(役割は一つだけ！)。
↓「結果をユーザ画面に返せ」と依頼されたファイルはせっせせっせとパソコン画面に検索結果を送ります。そして、ようやくパソコンのブラウザに「Strutsって何やねん」と検索した結果が表示されます。
今までの説明で、３つのファイルが登場しました。
もう一度見返してみて欲しいのですが、一つひとつ役割が明確に違っていたはずです。
これら役割をM・V・Cに当てはめると、以下のようになります。
コントローラ(C)
ユーザーのブラウザ画面からの依頼窓口、別のファイルへと実処理を指示する。
モデル(M)
コントローラからの指示で実処理を行う(この場合はデータベース検索処理)。
ビュー(V)
ユーザーの元へと処理結果を画面に返す。
このように、大きく３つの役割に大別してコードを管理します(順序がCMVになってるじゃねーかというツッコミはなしで。。それでもMVCモデルと覚えてください)。
繰り返しますね。
コードをM・V・Cの役割ごとにきっちり分類し管理していこう！という考え方がMVCモデルである。
・・・どうでしょうか。今なら少しはイメージが湧いてきたのではないでしょうか？
また、僕が最初に「モデルは処理！モデルは処理！」と連呼した理由ももう一度繰り返しておきます。この中で、明らかに英単語がその役割と一致しない仲間外れがいる。それがモデル。
なんでこんなふうに分けるのか？
一つのファイルに全部書けばいいじゃん？と思いますよね。
でも、1つのファイルに全ての処理を書くと、↓こんなデメリットが大きくなってきます。
あとでコードを読んだり修正したりする人が「直したい箇所をなかなか探せない」「何がしたいコードかよく分からない」ということが起きます。
例えるなら、Tシャツ1枚・パンツ１枚・靴下１足なら一つの引き出しでも大丈夫そうですが、それぞれ20枚(20足)ずつあったとしたら別々の引き出しに分けた方がゴチャゴチャにならずに整理できそうですよね。
そのような感じで司令塔役、処理役、画面表示役、この３つに分類して管理した方がいいんじゃないの、という考え方が生まれたのでした。
※ あくまでも「そうやって考えてみたらいいんじゃないの？」という方法論のうちの一つであってMVCが絶対じゃない、という点は留意しましょう。このような「MVCモデル」のような考え方を、しっかりした用語を使って表現すると「ソフトウェアを実装するためのデザインパターンの一つ」と言ったりします。数あるパターンのうちの、一つなのです。
これで「Struts2はMVCモデルを採用したJavaフレームワークである」の前半がざっくり理解できましたね。
つまり、
Struts2は「処理役・表示役・司令塔役の役割ごとにすっきりコードを分けて管理」するJavaフレームワークである
と言い換えられそうです。
あとは、後半の「フレームワーク」が何なのかさえざっくり分かれば何となく理解したつもりになれそうですね。
では、フレームワークとは何か？
日本語にすると「枠組み」です。
はい、よく分かりませんね。僕もよく分かりません。
分からないのでまずは引用します。
かみ砕いて言うと、さまざまなシステム開発を効率化してくれる機能群、と表現できます。機能群だけではなく、ソフトウェアの骨組みまでを用意してくれているため、少ないコードで意図する機能やデザインが実現できます。それぞれのフレームワーク特有の書き方を学ぶ必要はあるのですが、プログラミングのビギナーにとって、とてもありがたいものなんです。
CodeCampusより引用
オレンジ色の部分だけ注目すればOKです。
コード書く量が減らせて開発が楽だよ！
でも、新しく文法とか学習する必要はあるよ！
ということですね。
よく例えられるのは「カレーのルー」です。
素のJavaでWeb開発をするのは、20種類のスパイスの実をひとつずつ砕いてすりつぶして割合に気をつけて調合して塩加減も自分で調整しながらカレーを作ることです。
Struts2のようなフレームワークを使って開発をするのは、ルーをぶっこんでカレーを作ることです。
簡単ですね。
フレームワークはカレーのルー、それだけ覚えれば終わりでいいです。
これで「Struts2はMVCモデルを採用したフレームワーク」の意味がざっくり明らかになりました。
第１章の結論です！！！
Struts2とは・・・
Javaの「フレームワーク」で「MVCモデルを採用」している、のでしたね。これをさらにざっくり翻訳すると、
- 司令塔役のコード・処理役のコード・表示役のコードにしっかり分かれていて(=MVC)
- 少ない手間で簡単にモノが作れる(=フレームワーク)
ということになります。
この２つをざっくり頭にいれておくだけで良いです。最初はとにかく単純に考えることが肝心です。
この記事を読む前より、頭に定着した感覚があるのであれば嬉しいです。
・・・さて今まではあくまでも「MVCモデルとは」「フレームワークとは」という抽象的な話をしてきました。
第２章では、「Struts2を使ったより具体的なコード」を見ながらMVCモデルの動きを理解していきましょう。
最終的には、「おお、たしかにStruts2はMVCっぽい」と感じることができると思います。
Struts2でMVCモデルの動きを理解しておけば、Javaの他フレームワーク(SpringやPlayなど)や他言語のフレームワーク(PHPのLaravel/RubyのRails/PythonのDjango等)の学習も割とスムーズに進めることができるようになるメリットがあります
それでは、続きをどうぞ。
