読者です 読者をやめる 読者になる 読者になる

フレームワークとして共通化する部分の抽出

処理の整理の段階で大体分類は終わってるんですけど、基本的には、前回([id:shout_poor:20100817#1282021845])での整理のうち、「本処理」の部分が個別ロジックとなり、それ以外のところは共通化できると考えます。

以下、切り分けが微妙な部分の検討。

入力パラメータの整合性チェック

入力パラメータのチェックは、画面ごとに設計してしまいがちですが、本来は項目の性質によって横断的に決められるものです。例えば書籍の管理コードであるISBNコードは、どの画面であっても英数13桁で入力されなければ困りますし、日付型の項目であれば、その用途に関わらず、入力形式は原則アプリケーション内で一致させた方がいいでしょう。

従って、最低限の整合性チェックは共通機能として、同じ名称の項目であれば同じチェックがかかるようにします。

DBアクセス

DBアクセスは本処理に記載していますが、だからといってすべての個別ロジックに「DBに接続して、SQLをパースして、パラメータをバインドして、取得したデータをフェッチしてオブジェクトに展開する」というのを一々書いていたらたまりません。

個別に用意すべきなのは、

  • 参照/操作対象のテーブルと検索条件(SQL)
  • バインドパラメータ
  • 受け皿となるデータモデルオブジェクト

くらいのものなので、これを極力簡潔に書けるよう、周辺機能を構築していきます。

なお、今回はいわゆるO/R Mapper的なものは作りませんし使いません。必要なら後付できるので。

外部データ入出力

これもDBアクセスと同様、煩雑な手続きをフレームワークで吸収し、「何を」「どこに」送るかということを簡潔に書けるAPIを構築します。