- - PR -
Implimentクラスについて
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2008-06-13 13:18
こんにちは。
SpringなどのDI構造の場合、XMLの定義に合わせてImplement(抽象化)したクラスを利用しているのは何故なんでしょうか？ そもそも抽象化クラスの利点は何なのでしょうか？ 技術的な質問ではないのですが、参考書を読んでもその点がよく理解できないでおります。 | ||||
|
投稿日時: 2008-06-13 14:02
DIでは、xmlで実装クラスを切り替えられるわけですが、型の互換性を保証するために抽象クラスないしinterfaceが必要になります。
実装Aと実装Bがあって、両者に共通するメソッドはどんなのがあるの？っていう情報が必要になるでしょう？ | ||||
|
投稿日時: 2008-06-14 22:20
nagiseさん、ありがとうございます。
型の互換性ですか。 Hibernateでは後のWEBアプリの拡張・保守などの利点をうたってますが、XMLにテーブルの型＆バイト数を定義する事によって、厳密にチェックされている為頻繁にテーブル定義が変わったりする開発時、かなりデメリットの方があると思うのですが・・。 また、Springのコネクションプールは有用ですが、Hibernateを同時に利用する事で、JDBC接続の測定値でもパフォーマンスは落ちると言われてます。 しかも、HQLなる独自文法の為、今までSQLに慣れ親しんだSQLプログラマはかなり目新しく、開発効率も落ちると思うのですが・・。 これだけ、ソースが増え、手間も増えるのであれば、SQL文一行の方が全然保守しやすいと思うのですが・・。DIにこだわるのであればManager、DAO、Entityプラス共通のDB接続クラスを設けた方が簡潔に思うのですが・・。 デメリットばかり感じてしまうのですが、企業やPM達は何を基準にHibernateやiBatisの連携に踏み切っているのでしょうか？ 何か、愚痴っぽくなってしまいましたが・・。 | ||||
|
投稿日時: 2008-06-15 00:47
何故突然Hibernateへの文句が・・・？？
利点というよりも逆にJavaであるがための制約であると考えています。 実装が1つしかなく、一時的なテストであろうと、どんなことがあっても、 絶対に実装クラスを取り替えることがないのであれば、 具象クラスのみでもよいかと思います。 Javaにおける継承、実装の仕組みは、 クラスをプラガブルに取り扱うための機構とも言えるでしょう。 言語によってはダックタイプなどもあって、同じシグネチャなら、 型の互換に関係なく呼び出せる言語もあります。 そういう意味で、制約となるわけです。 | ||||
|
投稿日時: 2008-06-15 09:08
かつのりさん、ありがとうございます。
＞絶対に実装クラスを取り替えることがないのであれば、 これは、クラスが存在し、名前が重複しなければと言う事でしょうか？ XML定義では絶対パス(APP_HOMEを元に)を指定しますよね？ 同じXMLのAjaxでも具象クラス一つで出来ますし、Implementする必要も無いと言う事でしょうか？ よく、営業の人間がDIを連呼していますが、何の根拠を元に押してるんでしょうか？それとも、最新技術(もうずいぶん経ちますが)を知ってる、流行を追っているだけなんでしょうか？ そもそも、Hibernateは独自すぎる、コミットロールバックの制御もXMLで定義しなくてはいけないし、第一パフォーマンスが落ちるのなら利点が見当たりません。勉強しても無駄になるだけ。また、一時的なJavaの技術のにおいプンプンです。 Hibernateの悪口になってしまいましたが、わざわざ開発効率も落ち、制御もHibernateのみのソースで実装しなければいけない理由が分かりませんでした。Spring単体でSQL文を一行投げるのが一番保守しやすいのではないでしょうか？？ | ||||
|
投稿日時: 2008-06-15 09:35
その文句は営業の人達に言うべきであって、nagiseさんやかつのりさんに言う話じゃないと思います。
そんな事言われたって困るでしょ・・・。 >そもそも、Hibernateは独自すぎる、コミットロールバックの制御もXMLで定義しなくてはいけないし、第一パフォーマンスが落ちるのなら利点が見当たりません。勉強しても無駄になるだけ。 そう感じる人もいるでしょう。 ですが、だったらどうすればいいのかという行動に移る人はいませんが。 パフォーマンス第１というのも時代に沿わないレガシーな考え方ですね。 -- 以下、余談 まあ、ぶっちゃけ自分もHibernateはあまり好みじゃないです。 とはいえ、他の代替技術でHibernateのメリットを補える技術はあまりない為、現時点ではHibernateは妥当と考えてます。 iBATISも同様。 現状だとS2Daoが一番使いやすいかとは思いますが、S2ファミリーを使わざるを得ないのが難点かな。 | ||||
|
投稿日時: 2008-06-15 12:05
わたなべさん、ありがとうございます。
かつのりさん、nagiseさんに文句を言ってるつもりは毛頭ありません。そう感じられましたら申し訳ありません、不適切な表現でした。 ところで、Hibernateのメリットと書かれておりますが、具体的にどのような事でしょうか？例えばAction内で直接SQLを投げられるなどが嫌であれば、DI構造に執着するのであれば。 ＠アプリのAction ↓ BL(Appのビジネスロジック) ↓ ↑ Managerクラス(AppからのDBインターフェース)※会員取得など用途毎にメソッド作成 ↓ ↑ DAO(SQL実行クラス) ｜ ↑ ｜ Entity(Dataクラス) ↓ ｜ DBConection(DBコネクション) ↓ ＠DB これだけでも、独自クラス名の命名規則でDI構造を実現できてると思うのですが・・。 パフォーマンスもそうですが、ソースが多く煩雑になったり、デメリットしか感じないのですが・・。 はやりのDIですが、みなさんどう感じてらっしゃるのか、ご意見が聞けてうれしいです。 [ メッセージ編集済み 編集者: 未記入 編集日時 2008-06-15 12:07 ] [ メッセージ編集済み 編集者: 未記入 編集日時 2008-06-15 12:09 ] | ||||
|
投稿日時: 2008-06-15 17:41
え？XML定義ってなんの定義の話しですか？APP_HOMEってなんのパスですか？ XMLやAjaxについて、一体どこからやってきた話しなんでしょう？ Hibernateについてもそうです。 クラスの抽象化についてのメリット・デメリット これについて聞きたかったんですよね?もしかして私が勘違いしていますか？ ちなみに、Hibernateは遅いか早いかで言えば、 生JDBC+SQLより早い場合もあります。 トータルで遅い場合があっても遅延ローディングで、 体感レスポンスを早くするということも可能です。 データアクセスだけではなく、データアクセスの結果の操作についても、 抽象化されたフレームワークといえるでしょう。 ＃個人的にはHibernateは大嫌いですが・・・ | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。