この特集のトップページへ
＞
Chapter 6：ビジネスロジックの設計
6.8 考察とまとめ
以上で，ビジネスロジックに用意すべきメソッドはすべて実装したつもりである。とはいえ，実際にはいくつかまだ不足しているメソッドもあるだろう。たとえば，今回は履歴を参照するメソッドなどを実装していない。また，プレゼンテーション層を作ってゆくと，当初は予定していなかったさまざまな機能がビジネスロジックに必要となってくることもある。しかし，COMを使っていれば，単純にメソッドを追加するだけですむことも多く，のちに拡張が必要となってもたいした手間にはならない。
ただし，メソッドを追加したときにCOMのインタフェースID（IID）が変わってしまうと，プレゼンテーション層のアプリケーションをすべて再コンパイルしなければならない羽目になる。一度使い始めたビジネスロジックやデータオブジェクトを更新したい場合には，Visual Basicのプロジェクトのプロパティの［コンポーネント］ページにおいて，［バイナリ互換］を選択し，COMのインタフェースID（IID）を変更しないように設定しておくべきである（「2.4.1 Visual BasicによるCOMコンポーネントの実装」を参照）。［バイナリ互換］を選択した場合には，新しいメソッドを追加したり，新しいコンポーネントを追加したりすることはできるようになるものの，既存のメソッドの引数や戻り値の型や数を変更する操作はできなくなる。
本章では，Windows2000やCOM＋に関係ない，基本的なデータ操作や，特定の機能を実現するにはどのようなデータベース操作をすればよいのかなど，設計の部分まで含めて説明してしまったため，かなり冗長になってしまった。実際，いくつかのメソッドは説明を割愛することも可能だったし，サンプルプログラムとしてはやや複雑な機能まで実装してきた感もある。
ビジネスロジックというものは，単純にプレゼンテーション層から受け取った引数を加工してデータベース層に書き込んだり，逆にデータベース層から読み込んだデータを加工してプレゼンテーション層に返すものであるから，最も単純な形としては，データベーステーブルの「追加」「更新」「読み込み」「削除」という4つの機能さえ備わっていればよい。しかし，本格的なアプリケーションを構築するとなると，ユーザーの利便性を高めるために，それ以外の処理を実装しなければならないことも多い。たとえば今回は，データベースを削除するときにレコードを直接削除するのではなく，DELETEDFLAGというフィールドを使い，1度目の削除では削除ずみにするだけで，あとから復活させることもできるようにしている。本来，サンプルプログラムとしてはこのような処理を実装する必要はないだろう。
だが，サンプルプログラムとしてではなく，実務に耐えられるアプリケーションを実際に構築する場合には，ユーザーが誤操作することも考えられるため，適切なエラー処理をしたり，誤操作を取り消したりする機能を実装する必要がある。その分だけ，ビジネスロジックのプログラムは複雑になるわけだが，ユーザーに利便性を与えるという意味では仕方ない。
雑誌記事や書籍などでは，紙面の物理的な制限があることから，そういった雑多なことに触れられることは少ない。そして，サンプルプログラムも極力単純にするよう配慮される。そのため，読者が少々込み入ったことをしようとすると躓くことも多いと思われる。しかし，今回はWebでの公開であるため，紙面が事実上無制限である。そういった意味で今回は雑多な処理を紹介するよい機会だと感じ，筆者が過去の経験から実務に必要と思われた細かなメソッドまで実装し，解説してきた。その分，冗長で読み通すのは大変とも思われるが，データベースの構造やビジネスロジックの設計の趣旨などを汲み取って頂ければ幸いである。
あらためていうほどのことはないが，アプリケーションを構築ならびに設計する場合，顧客から提示された仕様のまま最低限の機能さえ実装すればよいというものではない。まず，どのような場面で使われるのか，何のために利用するのか，誰が利用するのか，といったあるゆる事象を想定し，実務に沿いユーザーが使いやすいように実装していかなければならない。そのためには，当初の仕様にはない雑多な処理も実装すべき場面も多いのである。
また，アプリケーションは常に正しく動作する保証はなく，サーバーが停止するなどのトラブルに見舞われるケースもある。そのため，アプリケーションは完全に動作するものであるという認識を捨て，容易にトラブルを解決できる機構やメンテナンスの効率なども考える必要がある。本章で作成したビジネスロジックのメソッドは，AllAdminロールに属するユーザーであれば自由に呼び出すことができるようになっている。そのため，AllAdminロールに属するユーザーは，いかなるテーブルのレコードも強制的に更新できる。そして，請求書を作成するときの処理は，メンテナンスの効率を考え，タスクとVBScriptを使って実装した。こうしておけば，サーバーの異常によって，万一タスクが停止した場合にも，手動でVBScriptのプログラムを実行することで強制的に請求書を再作成できる。
ところで，本章で示したサンプルプログラムのなかには，冗長で処理効率の悪い部分も含まれている。これは，速度よりも，わかりやすさを優先したためである。速度を重視する場合には，いくつかのメソッドを1つにまとめて処理速度を稼いだり，ループ処理している部分をSQLで処理するように置き換えたり，場合によっては処理をストアドプロシージャにまとめてしまうということも有効であろう。
次章からは，プレゼンテーション層のアプリケーションを構築してゆく。この連載では，プレゼンテーション層として，（1）Visual Basicによるプログラム，（2）IISを利用したWebアプリケーション，の2種類を作る。次章では，まずは前者のプログラムから順に開発してゆくことにする。
DOWNLOAD |
本章で作成したプログラムは，以下からダウンロードすることができる。また，COM＋のパッケージとしてロールの設定なども含めたものも一緒に置いておく。とはいえ，いまのところまだプレゼンテーション層を作っていないので，COM＋のパッケージの動作テストはできない。動作テストをするためには適当なテスト用のプログラムを作る必要がある。
プレゼンテーション層をまだ作っていないのになぜ作成したビジネスロジックが正しく動作するといい切れるのかと疑問に思う人もいるだろう。もちろん，動作テストをしなければ正しく動作するとはいい切れない。しかし，プレゼンテーション層は，別に本格的なアプリケーションではなくてもよい。筆者はビジネスロジックにメソッドを実装するたびにVBScriptによる簡単なテストプログラムを実行し，Access 2000でデータベースを参照するなどして，正しくデータが書き込まれているか，読み取れているかどうかなどを調査し，動作を検証した。実際にアプリケーションを構築する場合には，複数の開発者でビジネスロジック層とプレゼンテーション層を分担して開発することも多い。その場合，ビジネスロジック層を開発する者は，テスト用の適当なプログラムを作り，作成したビジネスロジックが正しく動作するかどうかをテストすることになるだろう。
なお，ソースプログラムの一部は，本文中で示したものと一部異なる箇所がある。異なる部分は，（1）本文中で記したプログラムは見やすくするために適時「_」を使って行を折り返しているが，ソースプログラムでは折り返していない，（2）データオブジェクト（DataObj.*コンポーネント）においてObjectContextオブジェクトのSetAbortメソッドの呼び出しをすべてDisableCommitメソッドに置き換えてある，（3）一部のコメントやメッセージなどの誤記を修正した，という点である。実際のプログラムの構造に違いはない。 このうち（2）の変更を施した理由は，「COLUMN ルートオブジェクトから別のCOMオブジェクトを呼び出すときの不具合」で説明したとおりである。COM＋の不具合により，SetAbortメソッドを使うと「'" メソッドは失敗しました '" オブジェクト」というエラーが返されてしまうからである。この問題は，Microsoft社のKnowlage Base Q255733で報告されている。この不具合は，即座にパッチが提供されるのではなく，Service Packによって修正される見込みであるため，当面は，ObjectContextオブジェクトのSetAbortメソッドの代わりにDisableCommitメソッドを利用するなどして，この問題を回避する必要がある。 SetAbortメソッドとDisableComitは機能が違うので単純に置き換えればよいというものではない。この違いについては，「 5.4.4 COMコンポーネントがトランザクションをサポートするには」を参照してほしい。
また，この問題以外にもCOM＋についての不具合がいくつか報告されている。COM＋の開発をしていて何か誤動作などの不安が生じたならば，一度Knowlage Baseで不具合が報告されていないかどうかを調べたほうがよいだろう。Knowlage Baseでは，「kbComPlus」をキーワードとすることで，COM＋に関する情報を検索することができる。また，「kbWinOS2000bug」をキーワードとするとWindows 2000の不具合の情報を検索することができる。 |
 |
Chapter 6 92/92 |  |
