- PR -

MVCフレームワークに関して

«前のページへ 1|2|3
投稿者投稿内容
edd
会議室デビュー日: 2002/04/21
投稿数: 11
お住まい・勤務地: 茨城県守谷市・東京都
投稿日時: 2002-04-25 13:14
>> サーブレット間のリクエストはURLには現れないのでばれることはないと
>> おもいますので、特定のパラメータがあるかどうかで十分ではないでしょうか。
> これ、とっても怖い気がするのは私だけですか？

セキュリティーに関してどこまでやるかというのは、運用環境にもよるのではないで
しょうか。
インターネットで一般公開する場合と、社内の部門内で使うものとはおのずとその
重要性は変わってくると思います。

>　Servletをたたくのはブラウザからしかできませんか？

別のサーバーからならｈｔｔｐの口しかないんでそれようのプログラムを書くか、
ブラウザーからアクセスかしかないと思います。

>親クラスをつくりフィルタ処理などは親クラスに実装しておいて、
>必ずこれを継承させるという開発標準ですが、規模が大きくなれば
>漏れも出てくるでしょうから、個人的には他の枠組みを探したくなります。

うちのところは、親クラスに、リクエストからのモデルの展開の自動化や
共通情報の引渡しなどの共通処理をのせてしまっている場合がおおいです。

漏れの話はいかんともしがたいですね。
設計レビューをしっかりできればいいんですが。


まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2002-04-25 18:02
> セキュリティーに関してどこまでやるかというのは、運用環境にもよるのではないで
> しょうか。

　まさにそのとおりです。
　社外だとしても、どこで何をさせるかというのは当然変わります。
　ということを意識しているのなら良いのですが、無条件で固有パラメータの有無のみで
　十分だと考えると怖いですね。

　ちなみに、リクエストのパラメータを次のJSPなどにHTTPのリクエスト経由で引き渡すのも
　とても怖いです。


> >　Servletをたたくのはブラウザからしかできませんか？
>
> 別のサーバーからならｈｔｔｐの口しかないんでそれようのプログラムを書くか、
> ブラウザーからアクセスかしかないと思います。

　HTTPを話すプログラムさえ書ければブラウザと同様のことができますよね。
　ログイン状態やが正常だという状態をパラメータでかけてしまったとしたら、
　画面遷移とか何とか関係なくそのシステムを操れてしまいます。

　チェック漏れの話もこめて、単一ServletをControllerにするのは
　コストの割にメリットが大きいだろうと思っています。
　当然、規模によっては逆に工数が増えるだけなので、JSP:Servletを1:1は、
　選択肢としてはありです。

　まあ、何が言いたいかというと、どの形でもメリットとデメリットがあって、
　盲目的に十分だとか必要ないとか判断するとどこかで泣きを見るから
　慎重に、ということなのでした。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2002-04-25 19:30
>そうゆう意味で遷移元は遷移先に依存するのではないでしょうか。
>要はその依存性をどうやったら小さくできるかだと思います。

単一フロントの場合は、もうデータの受け渡しまで抽象化しちゃいます。
所詮 HTTP で渡せる/HTML で表示できるデータなんて、数百*数百の文字列2次元表どまりなんで、問答無用に箱に詰めて裏側に渡しちゃう。
あとは、パラメータの命名規則でいろいろ決めうち、っすね。

---
Servlet : JSP = 1:1 にするぐらいなら、JSP に共通 header みたいので JSP 中心主義の方が遷移がわかっていいじゃん…とか思ってたんですが、

>うちのところは、親クラスに、リクエストからのモデルの展開の自動化や
>共通情報の引渡しなどの共通処理をのせてしまっている場合がおおいです。

なるほど、JSP だとこれがやりにくいわけですな。
JSP 表示のための PreProcess だったら JSP 内に埋め込むほうがすっきりしそうですけど、Post 処理だといまいちではありますねぇ。うーん、なんかすっきりする実装ないかなぁ…
<form action="<PageIdPostActionServlet>"> もげもげ。
ぬ、そうするとPageIdPostActionServlet さんがどこに飛ばせばいいかわからない場合があるのか…ぬぅ。


>チェック漏れの話もこめて、単一ServletをControllerにするのは
>コストの割にメリットが大きいだろうと思っています。

最大のデメリットは、すなおに作っちゃうと URL が変わらないこと。
まぁ、あらゆる URL を受け付けて自前でそれを解釈する人がフロントに立てばいいっちゃーいいんですけど。

# あ〜、はやくふつーに Filter 使えるようになりたい…
edd
会議室デビュー日: 2002/04/21
投稿数: 11
お住まい・勤務地: 茨城県守谷市・東京都
投稿日時: 2002-04-25 23:36
>ちなみに、リクエストのパラメータを次のJSPなどにHTTPのリクエスト経由で引き
>渡すのもとても怖いです。

同一コンテクスト内のサーブレットからJSPへの引き渡しでJSPのusebeanを使って
リクエストに引き渡しオブジェクトを埋め込むなら、ブラウザーや外部のプログラ
ムからＪＳＰへの進入は無理だと思います。
もっとも、その前のサーブレットで進入されたらおしまいですが。

># あ〜、はやくふつーに Filter 使えるようになりたい…
ところで、サーブレットのフィルターって、あの機能でどうして「フィルター」
という名前なのか、しっくりこないのは私だけでしょうか？
「フィルター」ってようは「ふるい」ですよね、サーブレットフィルターは
いったいなにをふるいにかけるんでしょう。
デザインパターン的にはチェイン・オブ・レスポンシビリティの亜種というところでしょうか。

＞まあ、何が言いたいかというと、どの形でもメリットとデメリットがあって、
＞盲目的に十分だとか必要ないとか判断するとどこかで泣きを見るから
＞慎重に、ということなのでした。

答えをおっしゃってしまいましたね。（笑）
そう思います。
たしかに現場によって条件がちがうので、それぞれ考えないといけませんね。
edd
会議室デビュー日: 2002/04/21
投稿数: 11
お住まい・勤務地: 茨城県守谷市・東京都
投稿日時: 2002-04-26 10:14
こんにちは、

>Servlet : JSP = 1:1 にするぐらいなら、JSP に共通 header みたいので JSP
>中心主義の方が遷移がわかっていいじゃん…とか思ってたんですが、

個人的な好みでは直ＪＳＰだとどのクラスにつなげてどうこうといったロジック
的要素が大きくなるんであまり好きではないんです。
ＪＳＰには基本的にusebeanで定義したオブジェクトとのやり取りだけを記述した
いなぁと...

ところで、Servlet : JSPの数の関係ですが、以下のケースではServlet : JSP = 1:ｎ
or command : JSP = 1:ｎにしたほうがいいと思います。
　・画面上のデータ構造がいっしょのもの。
　　例えば更新登録画面と更新確認画面。
　　ほぼ、おなじモデルのデータ構造を使うので、１つのSevlet or command で同じ
　　１つのモデルクラスを扱い、そのモデルをつかって、更新画面と更新確認画面
　　生成のためのデータ受け渡しを行います。

逆にServlet : JSP = n:1 or command : JSP = n:1 のケース。
　・エラー画面、検索画面などの共通画面。


commandはフロントコントローラーパターンで実装した場合です。
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）