松尾です。デルファイの本を5分ぐらい読んできました^^; 後、後輩とも議論。


From: 中村暁史 Nakamura Akifumi <BXQ04723 / nifty.ne.jp>

> １：
> Statementオブジェクトは「SQLのコンテナ」だと
> 書いていますが、そのわりに
> 
> Statement st=con.createStatement();
> String sql="select hogehoge...";
> ResultSet re=st.executeQueyr(sql);
> 
> などと、実際にSQLを投げる瞬間にSQL文を
> 与えるらしいのが不気味。

delphiだと、

Close;
SQL.Clear;
SQL.Add('select hogehoge...');
Open;

ていう感じでしょうか? 私としては、こちらの方がちょっと違和感があります
ね…

# 「Delphiプログラミング技法 Vol.1 入門編」を読んでます。


> delphiの「TQuery」クラスだと、SQL文を
> 属性として持たせて、openメソッドないしは
> execSQLメソッドで投げるんですけど
> 属性として持たせないっていうヤリカタが
> 世間では普通なのでしょうか？

私も世間ではどの様にDBにアクセスしているのかよくわからないんですけども、
どちらかと言うとSQL文はその場その場で実行するようなイメージがあります。
属性として持っておくというか、当該オブジェクトにクエリーが属していると
いうイメージなのはストアドプロシジャでしょうか。DelphiならTStoredProc
で、こちらなら分からなくもないです。


> delphiがコンポーネント指向(「属性を持たせる」という
> 仕様のほうが使い勝手的に圧倒的に有利)だってのは
> さておいたとしても、属性で持たせるほうが
> 気持ちよいように俺には思えました。

ビジュアルプログラミング環境におけるコンポーネント指向だからプロパティ
として持たさざるを得ない、或いはプロパティとしておいた方が便利だ、とい
うことは分かります。例えば、BeanでRDBにアクセスさせようと思えば、プロ
パティでSQL文を持たせてopenするイベントを送るとか、そういったやり方が
便利な場合があるでしょう。でも、それがビジュアルなコンポーネント指向で
ない場においても、気持ちよいかどうかは別の議論だと思います。

要するに、プロパティとして持たせておく実装はコンポーネント指向という要
請から来たものであって、DBアクセスという側からの必要性は特にない、と言
えると考えます。

--

まぁ両方のやり方を用意しておくってのもいいかもしれませんが…。

--

ruby-listより-projects向きかも…。