O/Rマッピングに一部批判的な理由と、昨日のテスト仕様書の作成思想

　O/Rマッピング批判を書くといって、書いていなかった気がするので今日は、その話。
　O/Rマッピングの概念的なことに関して、ウィリアムのいたずらは批判する気はない。有効性についても、否定する気はさらさらない。

　ただ、O/Rマッピングを素直に心酔してしまい、O/Rマッピングツールを導入しないといけないと考えると、昨日のテスト仕様書を作る部分がまったく理解できなくなってしまう。

　つまり、「オブジェクト指向とのミスマッチの解決」＝O/Rマッピング導入と考えられると、
　少々自動化の考え方で、問題があることが起こってしまうと思う。
　
　今回のブログは、その問題が起こる開発内容について、述べたいと思います。
　（解決方法やテスト仕様書について、つまり昨日のやばい話の続きで、なぜ、テスト仕様書が
自動化できるのか、どこの部分が自動化でき、それは、どういう手段でできるかは、またこんど）

　したがって、この問題は、ウィリアムのいたずらが、テスト仕様の自動化の際に必要になる考えをまとめた、独断と偏見です（便利な思想）。

　なので、真剣に反論しようとしないでね(^^;)

---

　O/Rマッピングは、RDBを利用する場合、かなり有効な手段であることはみとめます。
　ただし問題は、O/Rマッピングを行う理由が、「インピーダンスミスマッチの解消」であるならば、そのようなミスマッチは、RDBだけでは、ないんじゃないかい？

　シーケンシャルファイルだって、XMLで記述しないで、RDBのテーブルの中に入っているようなレコードみたいな形で保存すれば、ミスマッチだし、帳票も、オブジェクト指向に基づいた。。。というより、入れば入れちゃえ！っていう感じで作るからをミスマッチを起こす
　オブジェクト指向が出てくる前に出てきた通信プロトコルだって、オブジェクト指向を意識していないからミスマッチが起きて当然だし、プログラムからメールを出すときだって、メールはXML形式というわけではないので、ミスマッチを起こしてるかも。。

　つまり、オブジェクト指向とのミスマッチを起こしているのはRDBだけでなく、結構いろんなものが起こしているんだけど、その中で、RDBが有名だから、「O/Rマッピングツール」が出てきているんだと思う。

　なので、RDB,メール、帳票など、複数の物を使うとき、RDBのミスマッチ解消はO/Rマッピングツール、メールは、なんとかツール、帳票は何とかツールなどと個別にやっていたのでは、それらツールに対して個々にテスト基準を設けなければいけない。

　なんか、オブジェクト指向と、そのほかの資源に対するミスマッチ解消のための統一フレームワークがあって、そのフレームワークに基づいたテストがあれば、今度新しい、オブジェクト指向とミスマッチを起こす資源が出てきても、簡単なのに。。。
（そのフレームワークにO/Rマッピングも、ほかのツールも入る）

　と思いませんか？

　そんなフレームワークに基づいて、自動化と、テスト基準を考えるわけです。

　富士通な人へ：
　ていうことで、次の話はCBMとCBSだ。