これ、書いてなかったっけ？
MVCのコントローラーで何も処理しないで、転送したり、
モデルを作成しないで、コントローラーで全部処理する方法があるけど、
なぜ、MVCのコントローラーをわざわざ作って、
ここで、モデルデータとビューのデータを入れ替えるのか？
これには、主に３つの理由がある。
それについて、かいてみたい
■作業効率の観点
これが、よく言われること。デザイナーとプログラマーの分離。
ビューが変更になっても、ビューとコントローラーだけ直せばいいので
モデルに影響しない
モデルが修正になっても、モデルとコントローラーだけ直せばいいので
ビューに影響しない
しかし、コレには反論が有る
モデルを修正する場合、ほとんどが、項目追加・削除である。
項目追加・削除する場合、その項目を入出力しているビューがあるはずで、
モデルの修正は、たいていビューの修正も加わる
一方、ビューだけの修正の場合、表示のしかた、GUIの問題で、
このときは、一般にコントローラーが無くても、ビューだけの変更で
モデルに影響しない。
と考えると、コントローラーが無いときの修正とほぼ同じ程度の修正になる
したがって、この主張は、実はあんまり意味無い。
■ソフトウェア工学的な主張
Struts2で考えよう。
Struts2では、画面の値を設定するための処理加工の場所として、
以下の箇所が考えられる
（１）Action側で値の処理加工をして、
ビューであるJSPでは、その値をそのまま表示する
（２）Action側は、モデルのデータをいれ、
ビューであるJSPで処理を行う
（３）Action側は、モデルのデータをいれ、
ビュー内のSタグのパラメータで使われる
OGNL式で、処理を書く
（４）Action側はモデルのデータ
JSPもモデルのデータをHiddenで書き出し
Javascriptで処理加工する。
このうち、どれがいいのか？
ソフトウェア工学的には２つの観点から考える
（観点１）データの転送量が一番小さい
→サーバーからクライアントへ大量データを送らない
（観点２）制約が一番少ない
→できるだけ、処理が自由に出来る
まず、
（４）は、サーバーからクライアントにデータを送るので
観点１に反しているのでX
（ちなみに、プログラム的にもクライアント処理中に、処理前の
画面がチラッと見えたりなど、まずいことがある。
セキュリティ的にも、パスワードデータを埋め込んだりと、まずい
ことがある）
（３）に関しては、OGNL式に、プログラムなどの複雑なものは
λ式を使わないとかけないので、制約が大きい
（２）のJSPは、Sタグの属性の中にOGNL式を書くが、
そのOGNL式の中に、JSPで処理した結果を書けない
（OGNL式の中にJSPはかけない、エラーになる）
ので、制約がある。
とすると、両方の観点を満たす、（１）、Actionで書くのが一番
ということになる。これは説得力があるが、PHPなどでは、
正当化しにくい（Viewでもコントローラーでも、どこでも
同じように書けるから）
■セキュリティ等の観点から
セキュリティ的にいうと、
クライアントとサーバーの間の通信
サーバーとDBアクセス間
DBアクセスのためのパスワード
書き出しファイル
は、暗号化したいという要望があり、
かつ、その暗号化レベルは変わるかもしれない
（開発中だけでなく、開発後、将来）
これを、きれいに簡単に行うには、
DBアクセス
画面アクセス
パスワードなどの保存
ファイル
など、入出力をすべて暗号化、パスワード付きにすればよい。
（暗号化方式は、すぐに書き換えられれば良い）
それを簡単に実現するには、
ファイル入出力
画面アクセス
データベースアクセス
などを行うクラス（以下、アクセスクラスと呼ぶ）を用意し、
そのアクセスクラス内で暗号化処理をすれば、
アクセスクラス内のメソッドを書き換えるだけで、
暗号も書き換えられる。
そうすると、
・アクセスクラスの部分と、
・アクセスクラスの入力を元に処理をして、
処理結果をアクセスクラスに返す
部分がひつようになる。
ここで、
画面のアクセスクラスに相当するのがビュー
DBその他、サーバー側のアクセスクラスに相当するのがモデル
となると、
それらアクセスクラスの入出力を加工する
アクションクラス＝コントローラーが必要で、
ここは、暗号化の影響をうけないことになる。
これならば、いかなる言語であろうと、
コントローラーで組み変えることが正当化される。
MVCのコントローラーで何も処理しないで、転送したり、
モデルを作成しないで、コントローラーで全部処理する方法があるけど、
なぜ、MVCのコントローラーをわざわざ作って、
ここで、モデルデータとビューのデータを入れ替えるのか？
これには、主に３つの理由がある。
それについて、かいてみたい
■作業効率の観点
これが、よく言われること。デザイナーとプログラマーの分離。
ビューが変更になっても、ビューとコントローラーだけ直せばいいので
モデルに影響しない
モデルが修正になっても、モデルとコントローラーだけ直せばいいので
ビューに影響しない
しかし、コレには反論が有る
モデルを修正する場合、ほとんどが、項目追加・削除である。
項目追加・削除する場合、その項目を入出力しているビューがあるはずで、
モデルの修正は、たいていビューの修正も加わる
一方、ビューだけの修正の場合、表示のしかた、GUIの問題で、
このときは、一般にコントローラーが無くても、ビューだけの変更で
モデルに影響しない。
と考えると、コントローラーが無いときの修正とほぼ同じ程度の修正になる
したがって、この主張は、実はあんまり意味無い。
■ソフトウェア工学的な主張
Struts2で考えよう。
Struts2では、画面の値を設定するための処理加工の場所として、
以下の箇所が考えられる
（１）Action側で値の処理加工をして、
ビューであるJSPでは、その値をそのまま表示する
（２）Action側は、モデルのデータをいれ、
ビューであるJSPで処理を行う
（３）Action側は、モデルのデータをいれ、
ビュー内のSタグのパラメータで使われる
OGNL式で、処理を書く
（４）Action側はモデルのデータ
JSPもモデルのデータをHiddenで書き出し
Javascriptで処理加工する。
このうち、どれがいいのか？
ソフトウェア工学的には２つの観点から考える
（観点１）データの転送量が一番小さい
→サーバーからクライアントへ大量データを送らない
（観点２）制約が一番少ない
→できるだけ、処理が自由に出来る
まず、
（４）は、サーバーからクライアントにデータを送るので
観点１に反しているのでX
（ちなみに、プログラム的にもクライアント処理中に、処理前の
画面がチラッと見えたりなど、まずいことがある。
セキュリティ的にも、パスワードデータを埋め込んだりと、まずい
ことがある）
（３）に関しては、OGNL式に、プログラムなどの複雑なものは
λ式を使わないとかけないので、制約が大きい
（２）のJSPは、Sタグの属性の中にOGNL式を書くが、
そのOGNL式の中に、JSPで処理した結果を書けない
（OGNL式の中にJSPはかけない、エラーになる）
ので、制約がある。
とすると、両方の観点を満たす、（１）、Actionで書くのが一番
ということになる。これは説得力があるが、PHPなどでは、
正当化しにくい（Viewでもコントローラーでも、どこでも
同じように書けるから）
■セキュリティ等の観点から
セキュリティ的にいうと、
クライアントとサーバーの間の通信
サーバーとDBアクセス間
DBアクセスのためのパスワード
書き出しファイル
は、暗号化したいという要望があり、
かつ、その暗号化レベルは変わるかもしれない
（開発中だけでなく、開発後、将来）
これを、きれいに簡単に行うには、
DBアクセス
画面アクセス
パスワードなどの保存
ファイル
など、入出力をすべて暗号化、パスワード付きにすればよい。
（暗号化方式は、すぐに書き換えられれば良い）
それを簡単に実現するには、
ファイル入出力
画面アクセス
データベースアクセス
などを行うクラス（以下、アクセスクラスと呼ぶ）を用意し、
そのアクセスクラス内で暗号化処理をすれば、
アクセスクラス内のメソッドを書き換えるだけで、
暗号も書き換えられる。
そうすると、
・アクセスクラスの部分と、
・アクセスクラスの入力を元に処理をして、
処理結果をアクセスクラスに返す
部分がひつようになる。
ここで、
画面のアクセスクラスに相当するのがビュー
DBその他、サーバー側のアクセスクラスに相当するのがモデル
となると、
それらアクセスクラスの入出力を加工する
アクションクラス＝コントローラーが必要で、
ここは、暗号化の影響をうけないことになる。
これならば、いかなる言語であろうと、
コントローラーで組み変えることが正当化される。
アクセス
トータル
ランキング
