Servlet+JSPを使ったWEBアプリ構造について

質問

現在TOMCAT6.xにて生産管理システムの前段として在庫管理システムを開発しようとしています。雛形等は無く１から作成していこうと思っているのですが、システム全体の構造をどのようにするか結論が出ていない状況です。別の開発で行った構造をベースにしようかとも考えてもいます。プロジェクトメンバーと話し合った結果、２つに分かれました。
でも共通部分は同じ所があり、MVC構造（本来とは違うかもです）という所までは一緒です。
その２つの案とは、
(1)1つの機能毎（若しくは画面単位）に１つのコントローラー（サーブレット）を持たせ、そのサーブレットからモデルのインスタンス化及びＤＢへのアクセス（ここはもしかしたらマネージャークラス、若しくはDAOを持たせてそこで処理）を行ったり、結果をレスポンスするＪＳＰを呼び出したりする方法。
(2)１つのサーブレットだけ作成し、そこからＪＳＰを直ぐに呼び出し、ＪＳＰにてモデルやＤＢへアクセスしたりするDAO及びマネージャクラスの生成をし業務処理した後、そのＪＳＰ上で結果を返す方法（要はFrontControllerパターン）。

これは、今回に限らず他のシステムではどのような構造になっているのか、とても興味があります。
(1)がベストなのか(2)がベストなのか、はたまた「うちのシステムでは、こっちのほうがトレンドで用いてますよ」というご意見を頂ければ助かります。
本来なら、私が知っている限りの中で(1)と(2)のメリットとデメリットを書くべきかと思いますが、素のままのご意見をいただければと思います。

宜しくお願いします。

回答No.4

gigamac · ベストアンサー

Strutsを導入するのがベストかと思いますが、諸事情があるみたいで大変ですね。私は（２）がお勧めです。FrontControllerパターンとView-Helperパターンを導入されてはいかがでしょうか？
・FrontControllerパターンのメリットとしまして「全てのリクエストを集中管理できる」。
・View-Helperパターンのメリットとしまして「業務ロジックをビューから分離し易い」。
どちらかというと、J2EEの世界に入ってしまうのですが、では、ビジネスロジックはどうするかというと、TO(Transfer Object)を用います。
また、ＤＢや通信等はDAOパターンで決まりです。
詳細はインターネット検索をかけると出てきますので、そちらを参考にしてみてください。

この手法以外にはGoFパターン等ありますが、私は用いたことが無いのでなんともです。

お礼

ご回答ありがとうございます。
なるほど。EJBをお勧めという事でしょうか。
検討材料としてプロジェクト内で話し合ってみます。
新たな選択肢を提供いただき、ありがとうございます。

回答No.3

hegemon

MVC構造というのなら、(1)のほうが近いですね。(2)では、結局JSPがコントローラの部分まで担当してしまうので、処理と画面の分離が困難になりそうです。
ただ、よくあるMVCの構成では、下記のように入り口だけは(2)のようになります。

１．Controlとして、一つのサーブレットがPOSTされたデータを受けとる
２．入力ごとに適切なModelクラスを選び、データを渡して処理を行う
３．処理が済めば、JSPへフォワードする
４．Viewを構成するJSPが、表示するデータをモデルクラスから受け取り、HTMLを生成する

Coltrolは、入力に応じるべきModelと、処理結果を表示すべきViewを選び出し、呼び出すことに専念。
Modelはひたすらデータ処理に、Viewは画面表示に専念する。

Strutsなど、こうした仕組みを提供しているフレームワークを使うのがお勧めです。

お礼

ご回答ありがとうございます。
確かにその通りなのです。（２）はView部分に業務ロジック的なプログラミングを強いられます。そうなると、デザイナーとプログラマーとの喧嘩となり苦労してきた経験もあります。できればＪＳＰには極力ロジックを載せたくないと私も思っています。

>>Strutsなど、こうした仕組みを提供しているフレームワークを使うのがお勧めです。
実は検討材料としてStrurs2を入れようかという話もあったのですが、クライアント様の担当者様がシステム開発部門にいまして、その方がサーブレット＆ＪＳＰしか知らないので、かたくなにＮＧといってきているのです。Strutsの重宝さをプレゼンとかしたのですがダメでした＞＜。

回答No.2

askaaska

楽なのは(2)よね。
新しい機能を追加するときに
アプリケーションを設定しなおすわずらわしさがないわ。
ログも一箇所にまとめやすいし
とても"作り手"に都合がいいわ。

でも私なら(1)を採用する方向で持っていこうとするわ。
(1)の場合、基盤のメニューも別アプリになるとは思うし
いろいろ実装上面倒だけど
・後日追加する生産管理システムを追加しても
　既存の在庫管理システムに影響がない。
　　＊もし同じアプリケーションにした場合
　　　万が一の不具合で両方とも止まってしまう可能性あるわ。
・別VM上での運用も容易に可能
　　＊負荷が高い場合、考慮したいわね。

共通コンポーネントの管理や、アプリケーション間のデータのやり取りを
いろいろ考えておかないといけないけど
その点さえクリアしてしまえば"運用は"かなり楽になるわ。

また、別々にすることの利点として、
片方だけ動かして片方を使わない
なんて使い方もシンプルよね。
さらに新しい機能を追加することもやりやすいし
仕様変更による影響も片方だけになる。

大規模になるときほど分けたときの利点が大きいわ。

でも逆に小規模だともともと運用が楽なので
一緒にした方がいいかもしれないわね。

とりあえず私の意見はここまで。

お礼

ご回答ありがとうございます。
確かにその通りだと思います。
ちなみに別なシステム構造などご存知でしたら、ご教授いただけると助かります。

回答No.1

dyna_1550

昔よく議論になりましたが、僕の個人的な意見としては（１）だと思います。

分散開発もしやすいし、設計書も書きやすいし。
デメリットとしては、名前空間が狭くなるとか、やたらファイルが多くなるなどですよね？
開発速度を考えると（２）と考えるかもしれませんが、よほど似た処理、
もしくは、簡単な処理の画面遷移でこうする場合はありかもしれませんが、
（１）と（２）が混在するのは良くないと思います。

お礼

ご回答ありがとうございます。
（１）ですか。私も実は機能で分離できるので平行開発というメリット部分で良いなーと思うのですが、（２）を押しているメンバーは画面管理がし易いという面と画面＝機能という切り分けができて良いという意見もあります。例えば画面番号(Z01-001とか付けて)と設計書の機能番号と一致させ、機能－画面－設計書と言う形で同一管理するなんていう事ができると言っています。（１）はどちらかというと、設計書－サーブレット－ＪＳＰという管理になります。私はこちらがこのみなのですけど。んーーー難しいですね。