- - PR -
ORマッピングって、本当に実用的？
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-12-04 12:58
いつも拝見させて頂いてます。
現在、業務用でJ2EEベースの新しいフレームワークを開発中です。外資系の結構偉い会社と一緒に設計をしてまして、基本的にインテグレーション層にはCMPのEntityBeanを使うつもりでしたが、業務要件上必要になる複雑なSQLの実行とか複数行の処理能力の問題が提起され、DAOフレームワークをEntityBeanと共用しようとして使えるDAOのフレームワークを調査中です。 それで挙げられたのが幾つかありまして今調べている中ですが、そこで下記のような疑問が浮かびました。 ・そもそも、ORマッピングって、何のためのモノか？私的には下記のような目的ではないかと思いました。 → オブジェクトの世界であるJAVA側からDBのレコードをまるでオブジェクトのように使う事により、より純粋なオブジェクト指向のプログラミングが出来る。 → JAVA開発者が永続化層（DB？）の専門的な知識を知らなくても開発が出来るようにする。 → 永続化処理の自動化による開発の効率向上。 → 永続化装置（DB、ファイルなど？）をDAO層の裏に隠蔽する事により永続化層が変わってもプログラムの変更は最小限に抑えられる。 もし、上で間違いか漏れがありましたら教えて下さい。また、上についてですが、 → 純粋なオブジェクト指向にこだわるのはあくまでもただのこだわりでそれが現実的な効果がなければ無視してもいいと思います。 → 幾らDAOフレームワークが永続化層（常にはDB？）の操作を代わりにやってくれるとしてもその基本的な知識（トランザクション、ロック、分離レベルなど？）をもたずに作成されたアプリケーションが実際に使えるものになるか？ → 世の中に流行ってるDAOフレームワーク（EntityBean, Hibernate、Torque, JDOなど？）を採用するにはそれなりの学習コストが発生し、それがSQL文の書き方をならうより安いとはとても言えないし使い勝手がいいとも言えない（HibernateとTorqueの設定ファイルとマッピングファイルの書き方を理解するのにどれくらいかかるか？また、それらは本当に管理しやすいのか？）。 → 永続化層から完全に独立することはほとんど出来ず、それ位ならSQLの書き方に注意したり、必要な場合grepでDBMS依存的な記述だけ書き換えればいいじゃん？と思われる。そもそも、DBMSを換えるっと事なんかめったにないでしょう？ → パフォーマンスが重視される業務系のアプリケーションでDAOフレームワークで自動生成されたSQL文って、どうやってチューニングするんですか？チューニングされてないSQL文で十分なパフォーマンスが出ない場合の対処は？ で、個人的には単純にSQLが発行できて、その結果をJavaのオブジェクトで貰えればそれだけでも十分なのでは？と思っちゃいましたが皆さんの高見は如何でしょうか？ [ メッセージ編集済み 編集者: sumin 編集日時 2003-12-04 13:05 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 13:22
現在、Torque3.0.2で開発を行っていますが、学習を行うのにまず資料が少ないので
基本的な事は行えても、その先となると時間がかかります（英語が堪能な方なら、もう少しはましになると思いますが・・・）。 また、複雑なSQL（階層構造の形で取得するとか、複数のテーブルを結合して云々・・・）ということになると、直にSQLを書いて発行したほうが後々のメンテもしやすく、速度的にも速いと言うオチがまっています・・・・。 で、結局現在の使用方法は、1テーブルに対する単純な検索、追加、更新、削除の処理にのみ使用しています。 複数テーブルの結合とかも行えるのですが、その都度スキーマの書き換えを行うのは面倒かなあ、と。 使っていて、そう思いました。 もしかしたら、本題とずれているかもしれませんが^^; | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 13:24
純粋なオブジェクト指向云々よりも、ある程度の規模以上のシステムを作る場合、役割を 複数のレイヤに分け、それらのレイヤ間のやり取りを抽象化したアーキテクチャが必要に なります。データアクセスレイヤを抽象化しようとすると、EJBなりDAOなりの仕組みが 必要になります。
この辺は設計者の腕の見せ所でしょう。少なくともトランザクションを意識しないで設計 するのは無理ですよね。
永続層に限らず、フレームワークの使い勝手がいいと感じるには開発環境のサポートが必須 だと思います。その意味では現在のところEJB以外ではメリットは少ないでしょうね。
フレームワークを利用することによる自動生成のメリット(工数の削減、品質の向上)といった メリットは考えられませんか? それと特定のシステムでのDBMSを換えることはないでしょうが、プロジェクトによって使用 するDBMSは違いますよね。
例えばEJBであれば、その部分だけBMPにしてSQLを直接いじる場合はあるでしょうね。 その辺はケースバイケースです。
それで十分な場合はあるでしょう。ですが毎回自分でSQLを書くのですか? | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 13:31
多分、一人でORのO側もR側もやろうとするからめんどくさいなーと感じると思います。ORマッピングはOとRを分離することで、Oからフロントを担当するSQL知らない業務系の人と、Rからバックエンドを担当するSQL職人に役割分担できることにあると思います。一度、ブレーク処理を含むような明細データをループ処理するようなちょっと手の込んだ画面、帳票をJSPで書いてみると、オブジェクトのツリーでデータを保持してると探索が簡単で便利さが実感できるとおもいます。
それをORマッピングというと思うんですが 
| ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 13:57
プリンスさんへ：
それをORマッピングというと思うんですが ← 確かにそうかも知りませんが、今のORマッピングツールってあまりにも巨大になりつつあるのではないかと思われます。 また、その通り、Java側の開発者とDB側の開発者の分離が出来れば理想的ですが現実的には如何でしょうか？少なくとも私の経験ではプレゼンテーション層の担当者とビジネスロジック以下の層の担当者とを分けた事はあってもビジネスロジック層とDB層を分けた事はなかったりします。（これはより大きな規模になるとありだとは思いますが。） | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 14:19
その通りですが、フレームワークっていうのはあくまで土台でその上でアプリケーションを開発する人の知識を差してました。例えばOracleとか一般DBMSよりロックが多発するDB2を利用する環境でトランザクションの長さを意識せずのんびりと処理をしていたら凄いパフォーマンスの悪化に繋がりますよね。そんな差を全部隠蔽できるのは理想的でしょうけど現実的でしょうか？
開発環境のサポートっていうの例えばどんなもんでしょうか？
自動生成のメリットは考慮してます。XDocletとMiddlegenの採用は既に決まってます。
これは学習のコストの話になりますけど、例えばEJBとHibernateを共用する際にはEQLとHQLを習得しなければなりませんよね。それって実はただSQLだけ知ってれば全部解決される問題ですよね。じゃ、単純にSQLを習得する事とEQL、HQLを習得する事の費用対効果は如何でしょうか？どうせチューニングとかの話になるとSQLの知識が必要になるし。。これはぜんぜんukさんの意見に反論してるつもりではなく現実的な状況の中でもそうでしょうかと聞いているだけです。どうせ、どっちかを選択しなければならないんだったらどっちを取るかですよね。
毎回自分でSQLを書くのは確かに非効率ですしJAVAの開発者には負担になると思います。実は私も今までSQLを自動生成してくれるDAOフレームワークを使って来ましたが、それがDBMSがORACLEからDB2になるとひどい目に会ってしまいました。DB2はロックの仕組みとか分離レベルの指定によりORACLEを始めとする一般的なDBMSとはぜんぜん違うパフォーマンス（低下）を見せたので結果的にDAO層から自動生成されDB2に渡されるSQL文を全部見直すケースになった経験がありました。そんな場合、自動生成したSQLよりは自家書きした方が安全だと思いました。しかも今回設計中のフレームワークは基本的にDB2を想定しています。（嫌だ！！）有る意味、アプリケーションで発行するSQL文ってDBAが全部検討するのが当たり前と本とかには書かれてますが私が言いたいのは現実的な話です。 以上、ご意見お願いします。 | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 14:44
なんだか論点が混乱してきたのですが、もともとの疑問はORマッピングの実用性ではなかったでしたっけ？SuminさんのはなしではSQL文のオートマ/マニュアルのどっち？という印象をうけます。ORマッピングをするしないとSQL文の自動生成は違いますよね？私もSuminさんに賛成で、BMPの様にSQLは自分で書かないと無理と思います。(現状のCMR, EJBQLでは)
ただし、ORマッピングは重要だと思います。ViewHelperから手前のプレゼンテーション担当者にとってデータ構造がオブジェクトツリーになっていると非常にありがたいです。 | ||||||||||||||||||||||||||||
|
投稿日時: 2003-12-04 14:52
設計者、というのはアプリケーションの設計者を指しているつもりです。もし、アプリケー ションの設計者がトランザクションを意識しなくていいフレームワークを目的としている のなら、それは無理だと思います。そもそもトランザクションの概念はRDBMSを使わなくても 必須でしょう。
たとえばDBスキーマからEntityBeanやDAOやValue Objectを自動生成する機能です。 DAOツールの例を挙げられていましたが、EJBのDDを自分で記述していたら非効率なのは 明白ですよね。
えーと、こういうケースって現実にあるのでしょうか。そもそもそれらを永続層の利用側が 強く意識しなければならないとしたら設計に問題あると思いますが。
少なくとも現状では永続層の開発者はSQLの知識は必須でしょう。
SQLを知っていたらEJBQL(HQLは知りません)の習得はさほど難しくないでしょう。
少なくとも私の場合、EJBやらORマッピングツールを使うことで工数や作業負荷は確実に 減っています。それではいけないのでしょうか。ツールやフレームワークを作る人たちは 大変でしょうが(私もそのようなツールに関わったことあります)、使う人の負荷が減れば それでいいのでは? そうでないのなら本末転倒ですが。
DBMSの仕様によってSQLを見直すことはある程度仕方ないと思います。しかしこれって特殊 ケースではなくよくあることでしょうか。それと、複雑なジョインが必要なクエリが必要な 場合は確かに自動生成は向いていないでしょうね。そういった場合に局所的に書き直す手段 が担保されていれば問題ないと思います。 | ||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。