- PR -

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

1|2|3 次のページへ»
投稿者投稿内容
ペンギン
会議室デビュー日: 2002/04/14
投稿数: 10
投稿日時: 2002-04-14 03:27
お初にお目にかかります。

現在、JavaによるWEB系システム開発を行っている者です。
フレームワークの導入を検討しています。
一般的になっているMVCモデルで行こうかと考えてはいるのですが、
Model2を使うとしたら、Strutsのような出来合いのパッケージを
利用する場合が多いのでしょうか？
それとも、現場に適したものを自前で作る方がいいのでしょうか？

また、JSPからServletをIncludeし、そのServletでBeanを実行するような
形も考えているのですが、やり方としてはもう廃れてますか？
こっちの方が開発時間が短いような気もするのですが・・・

どっちにしろ、何をやるかによると思いますが、
中規模程度のコミュニティサイトだとするとどうでしょうか。
（抽象的ですみません）

フレームワークやデザインパターンに精通しているわけではないので、
お知恵をお貸しください。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2002-04-14 19:31
ありがちなパターンですが、仕様が確定していないなら、とりあえず JSP でプロトタイプを作って検討と同時に共通部分の切り出しと BL の Bean へのくくり出しとかやると楽かも。

「BL 部分を必ず JSP の先頭に固める」「コピペはせず、共通化が必要になったらクラスを作る」などをルールにしておけば整理も楽ですよ。

まぁ、開発人数、システム規模、要望によっていろいろ変わりますが。
ペンギン
会議室デビュー日: 2002/04/14
投稿数: 10
投稿日時: 2002-04-15 12:33
ご返答ありがとうございます。

＞ありがちなパターンですが、仕様が確定していないなら、とりあえず JSP でプロトタ＞イプを作って検討と同時に共通部分の切り出しと BL の Bean へのくくり出しとかや＞ると楽かも。

なるほど、そういうやり方もあるのですね。勉強になります。
「とりあえず」はJSPでささっと作った方が、作業も楽ですね。

＞「BL 部分を必ず JSP の先頭に固める」「コピペはせず、共通化が必要になったらク＞ラスを作る」などをルールにしておけば整理も楽ですよ。

これについては同感です。
以前、いくつかのメソッドをコピペして、結果的にそこにバグがあり、
すべてのクラスを直すハメになった苦い経験があります・・・
「これでもJavaのソースか？」などと思いながら、
人にいわれるまま書いたので。
周りでフレームワークについて話をすると、フレームワークを構成する
クラスをどうするか、という話が中心になってしまうのですが、
やはり、それ以前にいくつかルールを決めるべきですよね。

＞まぁ、開発人数、システム規模、要望によっていろいろ変わりますが。

この判断の基準をどこに置くかが自分の課題でもあります。
今考えているのは「このシステムのため」という明確な対象が無く、
今後のベースを決めたいというところで悩んでいます。
自分の周りには、Javaやフレームワークに精通している
人間もおらず、経験的にも浅い人間が多く、
開発人数も３・４人という案件が多いので、
Strutsのようなものを利用するよりは、
よりシンプルなものを自前でつくって、隅から隅まで把握している方が、
開発を進め易いのかななどと思っています。

ちなみに、Strutsの構造だと画面インターフェースの
入力フォームの変更などが、ActionクラスやActionFormクラスに
影響を与えてしまうと思いますが、これだと、
修正や改変作業の効率が悪い気がするのですが・・・
BLには影響しないように組めばいいと思いますが、
ActionとActionFormとJSPの結びつきは強いので、
システム構成によっては、無理が出てくる気もします。
そもそも認識が間違ってますでしょうか。
Actionを第一に考え、それに対応するJSPを作ると考えるべきなのでしょうか？

ああ、もっと勉強しなくては。
edd
会議室デビュー日: 2002/04/21
投稿数: 11
お住まい・勤務地: 茨城県守谷市・東京都
投稿日時: 2002-04-21 04:18
>それとも、現場に適したものを自前で作る方がいいのでしょうか？

私の経験だと、フレームワークなしでは考えられないと感じてます。

以下のことを考慮しだすと、既存のフレームワークでも機能不足なので
既存のフレームワークに手を加えるあるいはラッピングする方法で対応
してます。

・デバッグ方法の効率化
　　チームごと、サブパッケージごとにデバッグログが区別できる仕組み
　　運用時にデバッグログ出力をOFFにするなどの制御
　　デバッグが終わったコンポーネントのデバッグログ出力をOFFにする仕組み

・業務規制
　　ログインユーザーの権限や組織による、機能制限、
　　業務内容ごとの業務時間制限
　　システムエラーが発生したコンポーネントは修復するまで再度
　　実行させない仕組み

・エラー処理
　　どの項目にどう言ったエラーがあったかをユーザーに表示する統一的な仕組み
　　とくてい項目を赤くしたり、フォーカスをそこに移動した状態にするなど。
　　必ずつくるのでフレームワーク化すべき。

・システムエラー監視への通知
　　業務上の論理的矛盾はアプリ側でしか判断できないので、このときに
　　業務システムシステムエラーを発生させシステム監視システムに通知する。
　　エラー画面処理と連携して、エラーレベルでエラー処理制御を統一。


・画面構成とコンポーネント構成の関係の統一化
　　てきとうにつくると必ずごちゃごちゃになるので、指針をだして
　　それにのっとって作る方式をサポートするフレームワークを作ります。
　　また、関連がわかるような命名規約も必要です。

　　以下のような構成がよくつかわれます。

　　画面：サーブレット：ＪＳＰ：Bean:ビジネスロジッククラス（共通化）
　　１：１：１：ｎ

　　だいたいサーブレットはアクションの解析とビジネスロジックの選択
　　とし、Beanの生成をビジネスロジッククラスにさせる方法になりますね。

　　ビジネスロジック部分をEJBにするパターンもよくあるようです。

　　画面間遷移はサーブレットでその画面のアクションを判断して、
　　次の画面を担当しているサーブレットにフォワードします。

　　画面からのアクションを次に遷移する画面担当のサーブレットにする
　　方法もありますが、条件によって複数の画面に遷移する可能性がある場合
　　java scriptでformのactionを書き換えるなどの制御が必要になります。

　　javaScriptって意外に開発効率が悪いので、（良い方法がみつからないかぎり）
　　なるべく使わないほうがいいと思います。

ところで、MVCっていうのはSmallTalkのUIフレームワークですが、ほんとの意味の
MVCってウェブアプリではむずかしいのでないでしょうか。
たいがいMVCといった時点でMVCぽく役割をわけようとか、アーキテクチャーパターン
として言われることがおおいと思います。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2002-04-21 20:51
では、反論めいたものを。

引用:

eddさんの書き込み (2002-04-21 04:18) より:
私の経験だと、フレームワークなしでは考えられないと感じてます。

どこまでを「フレームワーク」と言うかによるとは思うのですが、
ここではかなり大きく統一的なものをフレームワークであると仮定します。
引用:

・デバッグ方法の効率化
　　チームごと、サブパッケージごとにデバッグログが区別できる仕組み
　　運用時にデバッグログ出力をOFFにするなどの制御
　　デバッグが終わったコンポーネントのデバッグログ出力をOFFにする仕組み

Log ユーティリティーがあって、必ずそれを使うというお約束で対応。
引用:

・業務規制
　　ログインユーザーの権限や組織による、機能制限、
　　業務内容ごとの業務時間制限
　　システムエラーが発生したコンポーネントは修復するまで再度
　　実行させない仕組み

ACLは、確かに面倒ですね。Servlet API で対応できる範囲ならいいのですが。
Filter を使えるようになるまでは、Servlet 一本でうけて ACL と処理・遷移を制御するか、JSP なりに共通のヘッダ処理をつけるしかありませんね。

ただ、汎用的な ACL フレームワークはえてして処理が重くなり、かつ管理も面倒になるという罠。
引用:

・エラー処理
　　どの項目にどう言ったエラーがあったかをユーザーに表示する統一的な仕組み
　　とくてい項目を赤くしたり、フォーカスをそこに移動した状態にするなど。
　　必ずつくるのでフレームワーク化すべき。

Log と同様。フォーカス移動うんぬんは JavaScript とも関連するのでなんとも。
ちゃんとやろうとすると、JavaScript の自動生成や taglib の使用など、
デザイン面に影響をおよぼす枠組みが必要になる。
引用:

・システムエラー監視への通知
　　業務上の論理的矛盾はアプリ側でしか判断できないので、このときに
　　業務システムシステムエラーを発生させシステム監視システムに通知する。
　　エラー画面処理と連携して、エラーレベルでエラー処理制御を統一。

これも Log なりと同様。Exception 群につめこめる。
引用:

　　画面：サーブレット：ＪＳＰ：Bean:ビジネスロジッククラス（共通化）
　　１：１：１：ｎ

要件によってこの辺の作りはかなり変わるかと思います。
処理中心のB2Bアプリ系で、画面遷移を完全にサーバ側で制御してよければ
1サーブレットですべてのリクエストをうけて、処理を経て JSP に飛ばすのが
よいでしょうし、画面中心のコンシューマ向けアプリならば、
あらゆる JSP を基本に、正常系遷移と外れる部分のみ例外処理、が親切かと。

引用:

　　javaScriptって意外に開発効率が悪いので、（良い方法がみつからないかぎり）
　　なるべく使わないほうがいいと思います。

JavaScript なんていう、使えないかもしれないもので何かをしようとするのはご法度でしょう。あくまで補助的手段、便利性の向上程度にしか使えないのでは。

引用:

ところで、MVCっていうのはSmallTalkのUIフレームワークですが、ほんとの意味の
MVCってウェブアプリではむずかしいのでないでしょうか。
たいがいMVCといった時点でMVCぽく役割をわけようとか、アーキテクチャーパターン
として言われることがおおいと思います。

HTTPの特性上、無理。:-b
ですが、http://www.nextapp.com/products/echo/ なんていうソリューションも。

正直なところ、Web でないアプリケーションの Web 表現であれば MVC も可能だと思いますが、Web アプリを Web ページのリンクによる連鎖をベースとしたアプリと捕らえて MVC するのは難しいかと。

---
余談。この手の話を考えてていつも思うのは、Model部分(実はViewの一部かもしれない)に実は2種類あるということ。
入力をうけて処理する部分と、処理の結果を受けて(あるいは受けないで)表示の準備をする部分。このあたりをちゃんと分離したモデルがスマートに作れないかなぁと妄想する今日このごろ。
edd
会議室デビュー日: 2002/04/21
投稿数: 11
お住まい・勤務地: 茨城県守谷市・東京都
投稿日時: 2002-04-21 22:35
こんばんは、

すいません、どこが反論になっているのかちょっとわからないんですが。

[quote]
しょむさんの書き込み (2002-04-21 20:51) より:
では、反論めいたものを。

引用:

どこまでを「フレームワーク」と言うかによるとは思うのですが、
ここではかなり大きく統一的なものをフレームワークであると仮定します。


たしかに「フレームワーク」ということばは大きい意味がありますね。
命名規約みたいなものから、プロジェクト管理の枠まで含めて議論する場合もあるでしょう。


引用:

　Log ユーティリティーがあって、必ずそれを使うというお約束で対応。


もちろん、つかいやすいユーティリティーがあれば全然オッケーですね。


引用:

ACLは、確かに面倒ですね。Servlet API で対応できる範囲ならいいのですが。
Filter を使えるようになるまでは、Servlet 一本でうけて ACL と処理・遷移を制御するか、JSP なりに共通のヘッダ処理をつけるしかありませんね。

ただ、汎用的な ACL フレームワークはえてして処理が重くなり、かつ管理も面倒になるという罠。


　現実には大概のことはよくあるポータルメニューシステムでほとんどのことができてます。


引用:

引用:

・エラー処理
　　どの項目にどう言ったエラーがあったかをユーザーに表示する統一的な仕組み
　　とくてい項目を赤くしたり、フォーカスをそこに移動した状態にするなど。
　　必ずつくるのでフレームワーク化すべき。

Log と同様。フォーカス移動うんぬんは JavaScript とも関連するのでなんとも。
ちゃんとやろうとすると、JavaScript の自動生成や taglib の使用など、
デザイン面に影響をおよぼす枠組みが必要になる。



社外に公開するものはそこら辺の注意が必要ですね、社内システムは統一化して開発を楽にするほうがいいと思います。
社内システムはブラウザーも特定できるのでJavaScriptをつかってもそれほど問題にはなりません。


引用:

引用:

・システムエラー監視への通知
　　業務上の論理的矛盾はアプリ側でしか判断できないので、このときに
　　業務システムシステムエラーを発生させシステム監視システムに通知する。
　　エラー画面処理と連携して、エラーレベルでエラー処理制御を統一。

これも Log なりと同様。Exception 群につめこめる。



その実装はありだとおもいますよ。

引用:

引用:

　　画面：サーブレット：ＪＳＰ：Bean:ビジネスロジッククラス（共通化）
　　１：１：１：ｎ

要件によってこの辺の作りはかなり変わるかと思います。
処理中心のB2Bアプリ系で、画面遷移を完全にサーバ側で制御してよければ
1サーブレットですべてのリクエストをうけて、処理を経て JSP に飛ばすのが
よいでしょうし、画面中心のコンシューマ向けアプリならば、
あらゆる JSP を基本に、正常系遷移と外れる部分のみ例外処理、が親切かと。

そこらへんは開発体制にもよりますね。
規模が大きくて画面単位にサーブレットのソースを管理したい場合は　１：１の
構成のほうが管理がしやすいのではないでしょうか。
画面ごと平行に開発がすすめられますし。

今やってるのは、おっしゃるような構成で入り口のサーブレットを１つにして、サーブレットがアクションにそったコマンドを生成し、コマンドがビジネスロジックの実行とＪＳＰへの引き渡しをおこなう方式なんです。
たしJ2EEパターンにも同じようながありましたね。


引用:

引用:

　　javaScriptって意外に開発効率が悪いので、（良い方法がみつからないかぎり）
　　なるべく使わないほうがいいと思います。

JavaScript なんていう、使えないかもしれないもので何かをしようとするのはご法度でしょう。あくまで補助的手段、便利性の向上程度にしか使えないのでは。


一般に公開するWebアプリはもちろんそうだと思いますが、社内システムではある程度使えると思います。　もちろん使用範囲は限定するべきでしょう。


ペンギン
会議室デビュー日: 2002/04/14
投稿数: 10
投稿日時: 2002-04-22 14:25
しょむ様、edd様、ご返答ありがとうございます。

フレームワークという言葉を大きく考えると、
認証やログなど、抑えなければならない部分はかなりあるのですね。
参考になります。

JavaScriptなんかは、ターゲットブラウザが多数あると、
どこまで使うかの判断が難しいですよね。

＞＞ edd様

引用:
ところで、MVCっていうのはSmallTalkのUIフレームワークですが、ほんとの意味のMVCってウェブアプリではむずかしいのでないでしょうか。
たいがいMVCといった時点でMVCぽく役割をわけようとか、アーキテクチャーパターンとして言われることがおおいと思います。


厳密には難しいんですね。初めて知りました。
なんか代わりになるような言葉が使われるといいですね。


＞＞ しょむ様
引用:
画面中心のコンシューマ向けアプリならば、あらゆる JSP を基本に、正常系遷移と外れる部分のみ例外処理、が親切かと。

これはつまり「JSPを基本にしてリクエストを受け付ける」という作りも
ありということでしょうか？
今、画面遷移をどうするかが悩みの種なんです。
最近の本を見ると、やたらと「リクエストをServlet一本で受ける」
というやり方が載っているのですが・・・
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2002-04-22 23:49
# 引用元がバラバラになっていますがごかんべんを

>すいません、どこが反論になっているのかちょっとわからないんですが。

あー、私の中で、「フレームワーク」といわれると、共通ユーティリティークラスの集合体ではなく、ACL、遷移管理、BL/PL生成、ログなどなどをまるまるひっくるめた(究極的にはDominoのような)ものが念頭にあったものですから。そうじゃなくて、ルール決めと共通クラス利用の徹底でもなんとかなるのでは、という意味での反論です。

> 規模が大きくて画面単位にサーブレットのソースを管理したい場合は　１：１の
> 構成のほうが管理がしやすいのではないでしょうか。
> 画面ごと平行に開発がすすめられますし。

ほんとに？それは CGI 的感覚をひきずってませんか？
大規模開発でかつ業務内容が中心の場合は、むしろ BL と PL を分業する場合が多いので、BL は業務単位で作り、PL は画面ごとで作るほうがいい気がします。
BL さんは、入力はともかく業務モデリングで画面遷移を掌握して、遷移に応じた業務を実行、表示に必要なデータをそろえ、表示するための JSP を呼び出す。みたいな。

> これはつまり「JSPを基本にしてリクエストを受け付ける」という作りも
> ありということでしょうか？

ありです。

一般的に MVC というと Servlet 一本で受けてという構造の方がわかりやすく説明しやすい(M = Bean or Class? / V = JSP / C = Servlet)ため、そういう方法がよく説明してあります。ただ、ここで Servlet:JSP が 1:N なのか 1:1 なのか、そのへんがはっきりしなかったりごっちゃになっていたりする説明はよく見かけます。

JSP 中心主義における C はちょっとわかりにくいのですが、HTML のみで書かれたサイトを考えていただけると、「リンク群」が C に相当するのがわかるのではないでしょうかね。たとえば、あらゆるページの上部(or 左部 etc)に「ナビゲーションリンク群」があるとすれば、それがコントローラであるという考え方ができます。Servlet:JSP = 1:1 な場合もほぼこのケースですね。Servlet はコントローラと言うよりむしろ JSP の前処理。

サイト全体の構造がほぼこれで満足できるとか、HTML のみで作られたサイトと同じ感覚を与えたい(たとえば任意の場所を Bookmark できるとか)場合は、こちらのアプローチの方がしっくりくるでしょう。

# 手前味噌ですが プロフェッショナル JSP 2nd ed.(上)の 6,7 章あたり。
# 英語の原文記事が alpha works か dev works になかったかな…


> 現実には大概のことはよくあるポータルメニューシステムでほとんどのことができてます。

ポータルメニューシステムってどういうものですか?
画面丸ごとを ACL 単位として、そこに遷移するメニューの表示のみを権限によって変化させる?
とすれば、URL 直指定による権限破りができてしまうので、結局は Filter 的機能もしくは JSP の先頭での共通処理が必要になるのでは。

----
あ〜、MVC に前処理後処理モデルがほしい…

[ メッセージ編集済み 編集者: しょむ 編集日時 2002-04-23 01:46 ]
1|2|3 次のページへ»

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