C# と VB.NET の質問掲示板

わんくま同盟

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト


(過去ログ 54 を表示中)
■30075 / )  Re[11]: SqlCommandBuilderによるデータ更新について
□投稿者/ 未記入 (7回)-(2008/12/17(Wed) 19:37:18)
ちょっとはましになってきたかな。

> しかし、明示的に指定する必要がないことと、「UPDATE文を使わない」という理由が
> どのように関係しているのか、わかりません。

それが理由だとは限らない。だから不明瞭だと言ったというなのですね。
なるほど、発言の意味は分かりました。そして…私にも理由はわかりません。
私がそれ(DAOアプローチ)が理由だとは一度も断定していませんよ。
読み直してもらえば分かりますが、私は推測として書いていますよ。
これは、たくボンさんも同じように推測として書いていますね。

その後は、SELECT文はベタだからUPDATE文を隠蔽する理由が分からんだとか、
ストレージを書き換えるのかとか、全件引っ張ってきていて非効率だとか、
*質問者がUPDATE文を使わない意図*とは関係ないところで、私の推測に対して
文句があるようでしたので、DAOによって SQL を隠蔽する開発方法がある、
ということを説明しました。

それに対して、質問者がそのような意図を持っていたのか不明瞭だと
私に対して言われても困りますよ。


> 私の意見は、「DAO 使う必要ないでしょ?」ということになるのかな?

そういうことになると思います。私はすでに述べていますが、DAOの優位性を
主張しているのではなく、DAOの存在を説明しただけです。
私自身、様々な理由で、DAOアプローチが最適な方法だとは思っていません。

> また、もし、SELECT 文が複数のテーブルから引用していたり、
> 主キーが複数列に付けられている場合、UPDATE 文を明示的に指定しなければなりません。

その場合でも UPDATE文をカスタマイズすることができますよ。
なんだ、結局 UPDATE文を書くんじゃないかって?
それなら、素直に UPDATE文を書けばいいじゃないかって?

まあUPDATE文、書きますけどね。全員が書く必要はないというのがミソです。
DAOパターンってそもそもそういうものですし。
それがカプセル化というものですよ。大規模開発で意味が出てきます。

> 列名を指定している部分が「べた書きだと思う」部分です。

質問者は「顧客C」を必要としていないと思いますよ。ADO.NET の実装の都合に
合わせて、主キーを指示してあげる必要があったというだけで。主キーを自動的に
取得して裏方でやってくれるDAOだって実現できないわけじゃないですし。
やはり、処理対象の選択行為を Where句を書かずに、ライブラリの機能で
おこなっているというのは「SELECT文をベタ書き」していないということになると
私は思っています。が、この話はもうやめておきましょう。大した意味を持っていないし
そもそも「ベタ」の定義も曖昧です。極端なことを言えば、パラメタ化クエリでさえ
「ベタ書き」かどうかで意見が分かれることもあると思いますので。

> 「SELECT 文も*直接*発行しないように出来るけど?」

そうですね。DAOアプローチを徹底するということもできますね。私もそう思います。
その上で、(私だったら) SELECT 文を書く、という理由はすでに述べましたので繰り返しません。

というかですね。昔からこういうアプローチってありませんでしたか?
私は好きではないのですが、UPDATE/INSERT/DELETE の直接発行を禁じて
データ更新はすべてストアドプロシージャを経由させるシステム開発とか。
見たり聞いたりしたことないですか?
DAOも考えの起点は、同じところにあると思います。

もしかしたら、あなたたちはストアドプロシージャでDMLを隠蔽するという
アプローチも見たことないのかもしれませんね。

おそらく、経験、想像力、脳味噌のいずれかもしくは複数が足りていない
のだと思います。UPDATE文を使わないと聞いて、最初に出てくるのが
「ストレージ書き換え」ですからね。馬鹿かと思いましたよ。

そしたら、皮肉だとか、赤面して反論だとか。馬鹿だと確信しましたよ。

返信 編集キー/


管理者用

- Child Tree -