- - PR -
MVCフレームワークに関して
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2002-04-23 09:18
>一般的に MVC というと Servlet 一本で受けてという構造の方がわかりやすく説明しやすい
>(M = Bean or Class? / V = JSP / C = Servlet)ため、そういう方法がよく説明してあります。 制御を集中させるのは、セキュリティのチェックやログの記録を一個所でやりたいとかという理由が大きいように思います。FrontControllerパターンの説明をみて。 http://developer.java.sun.com/developer/restricted/patterns/FrontController.html |
|
投稿日時: 2002-04-23 13:28
>あー、私の中で、「フレームワーク」といわれると、共通ユーティリティークラス
>の集合体ではなく、ACL、遷移管理、BL/PL生成、ログなどなどをまるまるひっくる >めた(究極的にはDominoのような)ものが念頭にあったものですから。そうじゃなく >て、ルール決めと共通クラス利用の徹底でもなんとかなるのでは、という意味での >反論です。 その点はまったく同意です。 要はどこまでやるかという話だとおもいます。 > > 規模が大きくて画面単位にサーブレットのソースを管理したい場合は １：１の > > 構成のほうが管理がしやすいのではないでしょうか。 > > 画面ごと平行に開発がすすめられますし。 > > ほんとに？それは CGI 的感覚をひきずってませんか？ > 大規模開発でかつ業務内容が中心の場合は、むしろ BL と PL を分業する場合 > が多いので、BL は業務単位で作り、PL は画面ごとで作るほうがいい気がします。 > BL さんは、入力はともかく業務モデリングで画面遷移を掌握して、遷移に応じた > 業務を実行、表示に必要なデータをそろえ、表示するための JSP を呼び出す。 > みたいな。 私は知らないんですがBL, PLって一般用語でしょうか。 Business Logic とpresentation Logicの意味でいいんでしょうか。 おっしゃられているのはビジネスロジックをサーブレットにのせるという前提 でしょうか。 好みの問題かもしれませんが、私どものアプリケーションでは、サーブレット は画面からの要求解析、ビジネスロジックの選択、ＨＴＴＰ固有ロジックをも たせ、次画面のサーブレットまたはＪＳＰのアドレスを知っているものとする 場合が多いです。 そして、データの取得や判断、チェックなどのビジネスロジックは別のクラス に書くようにしています。 この考え方のもとはその画面上のどの名前のボタンが押されたか、どうゆう 意味のデータがどうゆう名前で送られてきているかは画面定義固有の話なの で、画面構成の変更で変化するものととらえ、画面ごとのサーブレットにこ のことを吸収させるという意図なんです。 この構成では、画面ごとにサーブレットがあるのでそのサーブレットの処理 担当範囲はその画面を生成するためのデータ取得などの前処理と、その画面 からの要求によるロジック実行や画面選択の後処理となります。 画面遷移する場合は、パラメータを次の画面生成のためのサーブレットに 渡し、そのサーブレットに画面前処理を任せてしまいます。 分け方な律儀なんで、クラス数が増えるという難点はありますが、処理パターン が一定するので管理はだいぶ楽でした。 > > 現実には大概のことはよくあるポータルメニューシステムでほとんどのこと> >ができてます。 > > ポータルメニューシステムってどういうものですか? > 画面丸ごとを ACL 単位として、そこに遷移するメニューの表示のみを権限によっ >て変化させる? そうです。 > とすれば、URL 直指定による権限破りができてしまうので、結局は Filter 的機能 >もしくは JSP の先頭での共通処理が必要になるのでは。 キーパラメータのチェックなどを行ってサーブレット直接起動では動かないように しておけば、個々のフィルターは必要ありません。 |
|
投稿日時: 2002-04-23 15:58
eddさんの言うように「サーブレット
は画面からの要求解析、ビジネスロジックの選択、ＨＴＴＰ固有ロジックをも たせ」るのならば、これをControllerであるひとつのServletにやらせておく ほうが管理が楽ではないですか、というのがしょむさんの意見かと。 「次画面のサーブレットまたはＪＳＰのアドレスを知っているものとする」のは ソースコードに書いてしまう必要はなく、フラットファイルでもXMLでも、 Propertyでも、はたまたDBのテーブルでもいいわけです。 こうしてしまえばビジネスロジックはServletから呼べればいいだけであり、 Servletである必要は何もありません。 おまけに、画面遷移やアクセスコントロールについては、取り決めだけしてしまえば 各開発者は一切コードを書く必要がなくなります。 ということではないかなぁと思ってみたり。 |
|
投稿日時: 2002-04-23 19:12
まりりさんのおっしゃるとおりでございます:-)
遷移コントロールを、基本的に URL の飛び先として実装すると、コントロールが分散してしまうというデメリットがあります。 >こうしてしまえばビジネスロジックはServletから呼べればいいだけであり、 >Servletである必要は何もありません。 >おまけに、画面遷移やアクセスコントロールについては、取り決めだけしてしまえば >各開発者は一切コードを書く必要がなくなります。 です。私が大規模開発といってるのは、たとえば BL 処理を HOST に飛ばしたりするような場合です。 あらゆるリクエストをひとつのサーブレットでうけて、パラメータ、RequestURI、Cookie、Session に乗っているステータスなどなどから、呼び出すべき BL を決定して処理、返り値に応じて dispatch する JSP (場合によってはJSP表示のための前処理?)を決める、というフレームワークです。 BL を作る人はデザインは考えたくないし、PL を作る人は裏側の機能とか URL とかは考えたくないし、という場合(垂直分業したいとき?)には有効ですかね。あと、画面遷移がトランザクションになっている場合。 # = 複数のJSPで単一のトランザクション(業務単位)を実現する場合 eddさんのおっしゃっている JSP1 -> Post1-Servlet -> BL -> Pre2-Servlet -> JSP2 は、機能と画面が基本的に 1:1 の場合は、有効っぽいですね。 --------- それと… BL/PL は Business Logic / Presentation Logic の意です。 一般的かどうかは…(^^; まぁ、MVC な話をする時には共通用語かなぁと思ってましたが。 > キーパラメータのチェックなどを行ってサーブレット直接起動では動かないように > しておけば、個々のフィルターは必要ありません。 え〜と、この「キーパラメータのチェック」はどこに設定して誰が行うのでしょうか? [ メッセージ編集済み 編集者: しょむ 編集日時 2002-04-23 20:05 ] |
|
投稿日時: 2002-04-24 00:22
> あらゆるリクエストをひとつのサーブレットでうけて、パラメータ、RequestURI、Cookie、
> Session に乗っているステータスなどなどから、呼び出すべき BL を決定して処理、返り値 > に応じて dispatch する JSP (場合によってはJSP表示のための前処理?)を決める、という > フレームワークです。 この手の処理の大きなメリットは、クロスサイトスクリプティングだとか、 SQLインジェクションだとか、ちょっとした注意を怠ったがために起きる脆弱性を ControllerServletが責任をもって回避できる点ですね。 （そんな当たり前のことはServletコンテナがやってくれという話もありますが） あとは、前処理で専用のコレクションに放り込むとか、共通部分はBL側では だいぶ楽ができます。 かなり昔の話ですが、 ペンギンさん： > 入力フォームの変更などが、ActionクラスやActionFormクラスに > 影響を与えてしまうと思いますが、これだと、 > 修正や改変作業の効率が悪い気がするのですが・・・ > BLには影響しないように組めばいいと思いますが、 > ActionとActionFormとJSPの結びつきは強いので、 > システム構成によっては、無理が出てくる気もします。 「入力フォームの変更」で何が変わるかが問題だと思います。 入力の項目が変わるなんてのは大きな問題で、Actionにまで影響を与えるでしょう。 でも、レイアウトや文字の見た目に関連する部分は適当にいじってもらっても 何の影響もありません。 前者のような話が出てくるのは、要件をひっくり返すことになるので そもそも方向性が良くありません。 Strutsの方針が絶対ではありませんが、変わることを想定するのが正しいのか といった部分は抑える必要があると思います。 とはいえ、Webの画面の見易さなんてのはたかが知れてるので、 複数のJSPにまたがってひとつのトランザクションとすることには意味があります。 この場合、ページの分割が変わることもありえるでしょう。 こういうケースにはそれなりの仕組みを検討する必要が出てくるのだろうなと 思ったりもします。 JSP:ActionForm:ActionがN:1:1のイメージですね。 （Strutsを良く知らないのですが、こんなことできるのでしょうか？） |
|
投稿日時: 2002-04-24 09:59
こんばんは、
>eddさんの言うように「サーブレット >は画面からの要求解析、ビジネスロジックの選択、ＨＴＴＰ固有ロジックをも >たせ」るのならば、これをControllerであるひとつのServletにやらせておく >ほうが管理が楽ではないですか、というのがしょむさんの意見かと。 >「次画面のサーブレットまたはＪＳＰのアドレスを知っているものとする」のは >ソースコードに書いてしまう必要はなく、フラットファイルでもXMLでも、 >Propertyでも、はたまたDBのテーブルでもいいわけです。 単純に遷移する場合ならそれで十分だと思いますが現実はもう少し考慮が 必要だと思います。 というのは、遷移先の画面のための処理は何らかのパラメータを必要とす る場合が多いということなんです。 たとえば、一覧画面から１項目を選択してその項目の詳細を表示する場合、 一覧画面から選択したデータのキーを取得して、次の画面の処理に渡します。 詳細の画面を表示する画面がいろんな所から呼ばれる場合、同じ画面に 戻るために戻り先のサーブレットのアドレスも渡しておきます。 そして、違うある画面にあらたにボタンを追加して前述の「詳細表示」の サーブレットに遷移させようとする場合、遷移先のアドレスの設定（XML などの設定ファイル）と、遷移元遷移先が必要とするパラメータを準備 する処理を遷移元の処理に追加するというふうに２カ所のメンテが必要 になってしまいます。 そうゆう意味で遷移元は遷移先に依存するのではないでしょうか。 要はその依存性をどうやったら小さくできるかだと思います。 >こうしてしまえばビジネスロジックはServletから呼べればいいだけであり、 >Servletである必要は何もありません。 >おまけに、画面遷移やアクセスコントロールについては、取り決めだけしてしまえば >各開発者は一切コードを書く必要がなくなります。 >ということではないかなぁと思ってみたり。 画面生成＋前処理ロジックが分散しないかぎり、サーブレットを１つにする こと自体は全然オッケーだと思います。 今私のところのプロジェクトの１つでもmikiさんのご指摘のフロントコント ローラパターンでサーブレットを１つにする方式で設計がすすんでいます。 一方で私が気にしているのはこんなパターンなんです。 たとえば、データの一覧画面。 一覧画面って、遷移していった子供の画面で更新完了とか、照会完了 したら戻ってくる場合が多いと思いますが。 一覧画面-> 更新画面 -> 更新確認画面 -> 一覧画面 一覧画面-> 照会概要画面 -> 照会詳細画面 -> 一覧画面 この一覧画面を生成するためのロジックをどこに書くかなんです。 更新確認から更新が成功して一覧画面に戻る場合、処理手順としては 以下の用になります。 ->「ＤＢ更新処理」->「一覧画面用データ取得」-> 「一覧画面生成」 照会の場合はこうです。 ->「一覧画面用データ取得」-> 「一覧画面生成」 この「一覧画面用データ取得」から 「一覧画面生成」は 一覧画面に依存するので、この処理の入り口を決めておけば、 どの画面からもその処理の入り口を呼ぶだけで一覧画面に遷移 することができます。 またＤＢ更新処理は「更新確認画面」に固有の処理であり、 一覧画面生成処理とは分離させておきたいところです。 こうなることを前提でつくっておけば画面遷移の構成が変更になっても 修正でそれほどあわてることはありません。 >--------- >それと… は。（汗） >> キーパラメータのチェックなどを行ってサーブレット直接起動では動かないように >> しておけば、個々のフィルターは必要ありません。 > >え〜と、この「キーパラメータのチェック」はどこに設定して誰が行うのでしょ >うか? サーブレット間のリクエストはURLには現れないのでばれることはないと おもいますので、特定のパラメータがあるかどうかで十分ではないでしょうか。 現実には、ユーザーID、組織コードなどの共通情報は必ず引き渡す場合がおおいの で、直接サーブレット起動してもエラーで落ちてしまいます。 意識的につくるのであれば、チェック処理を先頭から呼べばいいのではないでしょ うか。 フィルター処理を呼ぶのと、変わりませんね。 |
|
投稿日時: 2002-04-24 21:09
皆様、ご返答ありがとうございます。
技術的にどうこうと言うのではなく、方法論としてどういう枠組みに するかという話になると、人それぞれ、思いがあるようですね。 私なんかは、単細胞なので 「 作成するファイルが多い ＝ 管理が面倒 」 などと単純に思ってしまい、Strutsのような枠組みに疑問を感じて、 書き込みをしたんですが・・・ 皆さんの書き込みを読む限り、色々なことを考慮して、 「サーブレット一本で〜」という形にして、 さらに、ロジックをどう分割するかを考えることにしたいと思います。 ＞＞まりりさん ＞「入力フォームの変更」で何が変わるかが問題だと思います。 ＞入力の項目が変わるなんてのは大きな問題で、Actionにまで影響を与えるでしょう。 ＞でも、レイアウトや文字の見た目に関連する部分は適当にいじってもらっても ＞何の影響もありません。 ＞前者のような話が出てくるのは、要件をひっくり返すことになるので ＞そもそも方向性が良くありません。 お客さんが「フォーム追加してくれー」なんて言い出した場合に、 すぐに対処できるようにフレームワークを規定するのではなく、 そういうことは開発以前に潰すってことですね。 
DB修正しなくちゃいけないですもんね。 ＞＞しょむさん ＞JSP 中心主義における C はちょっとわかりにくいのですが〜 略 〜 「Controllerがないぞ」 なんて思っていましたが、 そう考えると、見えてきますね。 逆にそういう部分がControllerになってしまうと、 システムの内容や作りによっては、管理しづらくなってしまう ということになりますね。 |
|
投稿日時: 2002-04-25 00:43
> サーブレット間のリクエストはURLには現れないのでばれることはないと
> おもいますので、特定のパラメータがあるかどうかで十分ではないでしょうか。 これ、とっても怖い気がするのは私だけですか？ > 現実には、ユーザーID、組織コードなどの共通情報は必ず引き渡す場合がおおいの > で、直接サーブレット起動してもエラーで落ちてしまいます。 Servletをたたくのはブラウザからしかできませんか？ > 意識的につくるのであれば、チェック処理を先頭から呼べばいいのではないでしょ > うか。 > フィルター処理を呼ぶのと、変わりませんね。 そこに落ち着くのです。 ひとつの解決策は、 親クラスをつくりフィルタ処理などは親クラスに実装しておいて、 必ずこれを継承させるという開発標準ですが、規模が大きくなれば 漏れも出てくるでしょうから、個人的には他の枠組みを探したくなります。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。