Webアプリケーションのフレームワークに必要な機能として以下のものが考えられます。
・画面遷移 ・MVC分離 ・入力チェック ・DB関係 ・ユーティリティ ・表示 ・ファイル操作 ・外部設定ファイル ・ログ ・例外処理 ・メール ・メッセージ ・CSV ・ダウンロード ・ファイルアップロード ・セキュリティ ・セッション管理 ・クッキー ・ユーティリティとしては以下の機能が考えられます 文字列操作 フォーマット変換、文字コード変換、置換、ソート ファイル処理 配列処理 プロパティ読み込み ・DB関係 トランザクション クエリー リザルトセットの扱い
これらの機能を利用する際、どのように行なうのかを規約として定めておきます。例えばDBへのアクセスであれば、十分な理由がない限り、これ以外の機能を使用する必要があるときには、個々のやり方に任せます。
すでに市販やオープンソースのフレームワークが出回っていますが、通常、あるプロジェクトで使う機能、使う手順はほんの一部です。そのため、簡単に使えるように、あるいは機能制限して形式を統一させるために、必ずラッパーを作り、そこからプロジェクトのメンバーがアクセスするように制限します。最初に、使用するフレームワーク、ライブラリを選びますが、プロジェクト専用にカスタマイズしたフレームワークは必要になります。
Strutsはコントローラの部分とViewの部分は規定されていますが、Modelの部分については規定がありません。したがって、プロジェクトで使う際には、個々に任せないで、その部分も統一するようにします。
基本的に、同じロジックが複数現れるようであれば共通化すべきです。フレームワークがサポートしていないからといって、同じロジックをダラダラ書くのは望ましくありません。あらかじめ重複しそうなロジックは、フレームワークで共通化しておくことです。
例えばDBアクセスにJDBCを使う場合、SQLを発行するのに、いちいちDataSourceからConnectionを取得し、Statementを取得し、ResultSetに結果を入れてなんてことをやっているプロジェクトも多いのですが、他の人がORマッピングツールを作らなくても、
connect(); execute(sql, params); commit();
でSQL文だけを発行すればいいようにフレームワークを作るべきだと思います。
そして個々の担当者が機能を実装するとき、形式を統一するためにテンプレートを作っておきます。こうすると、フレームワークに従ってコーディングするのが楽になります。これは何か一つ実装してみてサンプルとして提示し、他のメンバーも同じ形式に揃えて実装します。
フレームワークが複雑であれば、学習に要する時間は増えます。学習した内容はそのフレームワークでしか使えないので、スキルは流用できません。
フレームワークのおかげで、言語のすべてを知らなくても、ビジネスロジックに専念できるといううたい文句がよく言われますが、チームのうちだれかはフレームワークに精通している必要があります。問題があればその人に聞くようにして、個々の担当者がすべてを勉強する必要がないようにしておきます。
そしてソースはその人が必ずチェックするようにして、規約どおりに記述するように修正します。
