みんなの「教えて(疑問・質問)」にみんなで「答える」Q&Aコミュニティ

こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

締切り済みの質問

Strutsなどのフレームワークが必要な開発って

JAVAを勉強している者です。
これまでJSPやサーブレットを使って、ある程度のシステムが作れる程にはなったのですが、フレームワークの事が気になっています。

少し「Struts」の勉強をしてみましたが、使いづらさと、表示画面への
柔軟性の無さなど、良い面が見つかりませんでした。

また、HTMLベースのソースコードも、フレームワーク独自の形があっ
たり、TomcatなどJAVA側のバージョンアップで不具合が生じる可能性
なども、耳にしました。

●そこで思ったのは、フレームワークを使う状況というのは、次の様な
時なのではと思っています。

・エンジニアのレベルが、時間さえあれば、一人でJSPやサーブレット
 を使ってシステムを作り上げる人と、「if」文や「for」文などの
 本当の基礎しか知らない人が混在した開発環境の時。

・開発プロジェクトで、開発人数が多く(十数人など)大規模なシステ
 ムで、柔軟性や工期短縮よりエンジニアの管理をする必要がある時。

●逆にこんな時には必要がないと考えています。

・携わる開発者が、一人でサイトを作れるレベルであり10人以内程に
 よる規模のシステム作成時。

・表示画面用のファイルと、他のプログラムファイルを分ける事
(MVC)を意識しすぎる事より、システム変更への柔軟性や、工期が
 早くなる事が分かった時。

・エンジニアのやりがいを引き出す為。

※個人的には、入力画面はともかく、出力結果などをMVCにこだわると
 あまり良い作成が出来ない気がしています。
 また、出力画面と処理用プログラムのファイルを分けた場合には、
 ソースの確認や編集が行いづらくなります。

 ただ、フレームワークを使わない時は、事前にエンジニアどうしで、
 一定の関数を使う事を基本条件にすると便利かもしれませんね。
(例えば、~本に載っている関数を使用する等)

 もし決まった関数以外で他の関数を使う時は、他のメンバーの了解
 を得る等のルールがあると良いかもしれません。
 (Eclipse関係の入門書とプラスαの関数で大抵の事は出来るのではと思っていますが...)

 多分こうした方が、フレームワークを使うより、エンジニアのやりが
 いも向上するし、結果的には効率も上がりそうな気がしています。

 また、上記のフレームワーク条件も、完全にそのようにしなければ
 ならないのではなく、状況や必要に応じて判断することが大切なの
 ではと思っています。

 もし、他にフレームワークのメリット・デメリットがありましたら
 教えていただけましたらと思っています。

投稿日時 - 2007-10-07 11:44:56

QNo.3408159

暇なときに回答ください

このQ&Aは役に立ちましたか?

3人が「このQ&Aが役に立った」と投票しています

回答(2)

ANo.2

こんにちは。

フレームワーク(枠組)という言葉通り、よい意味でも悪い意味でも「型にはめる」のが、フレームワークによる開発だと思っています。

 共通処理をフレームワークが吸収することにより、初心者が犯しやすいミスからシステムを守ることができ、プログラム毎の品質のバラつきを抑えることが出来ます。 「共通部品」のような考え方でもこれは可能ですが、共通部品はユーザープログラムから呼ばれる物なので、共通部品を使わずにコーディングされてしまうとアウトです。フレームワークではユーザープログラムがフレームワークから呼ばれるので、より安全です。
反面、熟練したエンジニアならばもっと効率的なコードを作成できるような場合には、フレームワークは足枷になると思います。

上記以外に、私は保守性の高さをメリットの一つに挙げたいと思います。
ここでいう保守性は「MVCを分離した方が保守性が高い」というような観点ではなく、(例えば)Strutsというフレームワークが世に広く普及しているという単なる事実による、保守性の向上です。
プロジェクト独自のフレームワークを採用している場合、新規要員を保守にアサインするに当たり、そのフレームワークの導入教育が必要となります。Strutsのようなメジャーなフレームワークを採用していれば、このような教育の手間をある程度削減することが出来ます。また要員の確保も「自社フレームワークでの開発経験がある開発者」よりも「Strutsベースの開発経験がある開発者」の方が容易です。

従って、下記の2つのケースについては私は一概には賛成できません。
開発後の保守も含めてトータルで考えるべきだと思います。

>・携わる開発者が、一人でサイトを作れるレベルであり10人以内程に
> よる規模のシステム作成時。
>
>・表示画面用のファイルと、他のプログラムファイルを分ける事
>(MVC)を意識しすぎる事より、システム変更への柔軟性や、工期が
> 早くなる事が分かった時。

なお、下記については目的と手段が入れ替わってしまっているため、理由とすべきではないと思います。趣味の開発ならばよいですが。
>・エンジニアのやりがいを引き出す為。

下記のご意見については全面的に賛成です。
>また、上記のフレームワーク条件も、完全にそのようにしなければ
>ならないのではなく、状況や必要に応じて判断することが大切なの
>ではと思っています。

投稿日時 - 2007-10-10 00:24:48

お礼

お返事ありがとうございます。

フレームワークを利用するかの判断は、開発内容や状況をよく考えて
行っていく必要がありますね。

投稿日時 - 2007-10-10 19:38:06

ANo.1

Strutsは基本FWです。
普通は、そのプロジェクトに合わせて、
ログ出力やDB接続などの
色々なライブラリを組み込んだり、
トランザクション管理用の共通関数やベースクラス
を作成して使用します。

また、LookupDispatchActionクラスなど、
MVCでのM(モデル)を構築するのを簡便化するクラス
も用意されています。

.net開発のように
コンポーネント指向でなおかつ、
DB接続などが用意されていても、
WEBアプリを作成する場合、
トランザクションの管理は欠かせません。

StrutsやTarbineのような
オブジェクト指向型FWは、
プロジェクトのルールを制約化するような
共通関数や基本クラスなどを作る基礎工事を行うため、
プロジェクトの方向性から外れたものを作るのは困難となるため、
工数がある程度読めますが、
自由度が少ないため、難易度の高いPGが出てくると、
その工数が跳ね上がります。

他方、VBやDelphi、.net、ClickFW(Java)などの
コンポーネント指向型FWは
個々のコンポーネントにある程度業務要件を満たすような
機能を持たせるため、
大量の本数および、工数が発生することでしょう。

メリットデメリットは仕方ありませんが、
アプリケーション開発において
いかに工期の短縮、簡便化を図るかということは至上命題です。
そこに能力を費やすことが重要なのだと思います。

投稿日時 - 2007-10-08 12:11:18

補足

すいません・・・
お返事へのお礼の内容なのですが、「ワークフロー」の部分は、「フレ
ームワーク」で置き換えて読んでください。
なんだか寝ぼけて書いてますね。
お恥ずかしいです。

投稿日時 - 2007-10-08 19:38:36

お礼

お返事ありがとうございます。

開発案件で、ワークフローを使うべきかどうかの見極めは、難しいようですね。

私の知っていたワークフローを使った開発で、顧客との最初の提示より
遥かに長い工期になり、数年経っても完了しない状態が続いていました。

きっと、そのワークフロー内では解決が難しくなり、工数が跳ね上がっ
たのかもしれませんね・・・

開発においては、ワークフローを使うべきかどうかや、使うとしても何
処まで使うべきかなどを、開発内容や開発環境をよく考慮して行う必要
がありますね。

投稿日時 - 2007-10-08 19:29:00

あなたにオススメの質問