- - PR -
拡張フレームワークについて
1
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2005-08-18 18:59
現在あるフレームワークを拡張し、さらに業務処理のみの実装に近づけようと思っております。
そこで・・・フレームワークの拡張ってどうやるかよくわからないんです??? Strutsなどでもいいので、実際にフレームワークを直接実装に使うのではなく、さらにラッピングした拡張版を作成するノウハウが書かれた本とかネットとかご存知の方いらっしゃいますか? まるで糸口がなくて路頭に迷ってます・・・。 ご存知の方がいらっしゃいましたらご教授の方よろしくお願い致します。 |
|
投稿日時: 2005-08-18 20:39
フレームワークと言っても多種多様ですし、「なぜ、このようなフレームワークになったのか?」という思想自体も多種多様です。
「Strutsなどでもいいので、」ではなくて、どのフレームワークを・・・という事をまず決めない事には誰も話す事が出来ないのでは無いかと思います。 (まず、何か一つフレームワークを使いこなす事が出来るようになってからでないと、拡張なんて考えるのはまず無理です。) |
|
投稿日時: 2005-08-22 13:01
けんたさんの考える拡張フレームワークは、
業務依存のものと読み取って、意見いたします。 (フレームワークの開発での拡張フレームワークをお考えの 場合は見当違いですのでご了承ください。) 業務処理依存の拡張フレームワークの目的は何でしょうか? 保守性の確保? 開発効率の改善? 製造レベルの補完? 私が思い浮かべる主な目的です。 これらを満たす拡張フレームワークは、開発における、 ノウハウ、技術、j2eeを利用するアーキテクチャの真髄ともいえる、 各組織の重要な資産です。 また、業務や開発形態などの依存性が高く、同じものを同じ組織内で 流用することさえも、難しいと考えています。(理想は、流用と拡張) そうした、ノウハウが外部に公開されているとは個人的に考えにくいです。 そのため、情報提供元を知っているわけではないのですが、 私が考える拡張フレームワークのポイントを参考までにあげておきます。 (開発形態に依存します。) 1.同一の表示フォーマット(テーブルやセレクトボックスなど)の オブジェクト化 例えば 業務によって、表示レイアウトなどが統一されている場合、 などは、専用のオブジェクトを用意し、ロジッククラスで作成したものを、 そのまま表示できる、カスタムタグを用意する。 2.広義オブジェクトの隠蔽 strutsなどのフレームワークは、限りなく広義なフレームワークで よく言えば、”拡張性豊富”、悪く言えば、”何でもあり”。 そのため、実装方法は多種多様に存在し、プログラマによって、 まったく違った実装をしてしまう、なんて経験があります。 (ある箇所ではセッションを多様、ある箇所では、ゴリゴリ画面に 貼り付けてある、などなど) そのため、業務に必要な固有の最低限のオブジェクトを準備し、 広義なオブジェクトを隠蔽して、実装方法限定統一したりします。 例えば request, response, などをラッピングし、 セッションを使用して欲しくないのなら、そこでアクセスできないようにする。 レスポンスの出力ストリームへの出力方法を統一しておくなど。 また、strutsであれば、actionクラスをラッピングし、 request, response を定義した、別のオブジェクトで使用するように 限定するなど。 3.トランザクションの統一化 トランザクションが必要な場合、 多段コミットは必要か? それとも、1リクエスト1トランザクションか? DBは複数アクセス行なうか? などを考慮して、それに合うように強制的に処理を行なうように action, logic, db access の一連の処理に親クラスを準備して 実装するなど。 重ね重ね、言いますがあくまで業務依存です。 本来は、一度、何がしらのフレームワークを利用して、 開発を行い、そこで生じた業務依存の問題点などを補うために、 次の開発に、拡張フレームワークを使用することが望ましいと考えます。 ただ、闇雲に拡張フレームワークを準備して、 フレームワーク依存のため、開発中に仕様を 満たせなくなるなんてこともありますので、 冬寂さんのおっしゃるとおり、一つのフレームワークを利用して、 ノウハウを蓄積することから、はじめるべきかと結論付けます。 |
|
投稿日時: 2005-08-22 16:00
冬寂 様
wine 様 ご連絡遅れて申し訳ございません。 お二人のアドバイスを参考に、調査を進めたいと思います。 ご多忙の中ありがとうございました。 |
1