| ■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文を使わないと聞いて、最初に出てくるのが
「ストレージ書き換え」ですからね。馬鹿かと思いましたよ。
そしたら、皮肉だとか、赤面して反論だとか。馬鹿だと確信しましたよ。
|
|
