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

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

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

Re[2]: DB更新データの渡し方について

分類:[.NET 全般]　

お世話になっています。
現在コーディング時のルール決めを行なっておりその際
のデータの渡し方についての質問です。
Windowsアプリケーションで環境はWindowsXP/VB2005です。

例えば電話番号帳アプリを作成する為に以下例の用に
FormHogeに登録データ用のTextBoxを4つとDBへの追加の為
の追加ボタンを配置します。

【FormHoge】
　 ●登録データ用
・ユーザID
・名前
　・住所
　・電話番号
●ボタン
・登録

テーブルへの追加は、別のクラスDataAcessHogeHoge
で行ないますが、この場合にFormHoge→DataAcessHogeHoge
へデータを渡す場合にどのようにするのがよいのでしょうか？
私が考えているのは以下のパターンです。

　1.FormHogeの各コントロールをPublicにしてDataAcessHogeHogeからFormHoge.・・・にて取得する。

　2.DataAcessHogeHogeにデータ取得用のプロパティを準備して渡す

　3.登録処理の引数として各値を渡す

この例の用に数が少ないということであれば2or3で行なっても手間がかからず
いいですが、実際の業務では20項目以上あったりすることがありプロパティを
準備するのが面倒だから1でいいじゃんという人もいます。ただ、カプセル化の
概念からいけば1の方法は個人的にはあまり好きではないです。

"リファクタリング　プログラミングの体質改善テクニック"
の中に引数オブジェクトの導入というテクニックが掲載されており
これを導入しようかと検討していますが、今回の例ではただのデータクラスに
なってしまいます。
上記本の中にはデータクラスは、コードの不吉な匂いということで
挙げてありますので矛盾するような気がしています。

この例は業務アプリケーション開発ではよくあるパターンだと思います。
是非ご意見をいただけたらと思います。

私ならばインスタンスを構造体として定義してHogeDataクラスに渡します。

まず、もう少しわかりやすく書きましょう。
設計の話なのでデータソース(DB)が何かによって話は変わると思います。

> 　1.FormHogeの各コントロールをPublicにしてDataAcessHogeHogeからFormHoge.・・・にて取得する。
問題外です。なぜDataAccessからFormのコントロールにアクセスするのですか？

> 　2.DataAcessHogeHogeにデータ取得用のプロパティを準備して渡す
この中ではこれでしょうか。ただしDataAccessHogeHogeクラスがどんなクラスなのかはわからないですが。

> 　3.登録処理の引数として各値を渡す
実際の業務システムを開発しているなら、仕様変更に迅速に対応できますか？
作りっぱで良いなら問題ないですが。

> 準備するのが面倒だから1でいいじゃんという人もいます。ただ、カプセル化の
開発の経緯や期間もあるので、一概には言えませんが、こんなことを言う人とは一緒にシステムを
開発したくないですね。

> "リファクタリング　プログラミングの体質改善テクニック"
> の中に引数オブジェクトの導入というテクニックが掲載されており

誰もがこの本を読んでいるとは限らないので、この手法と言われても回答のしようがありません。

私ならVS2005で開発するなら厳密に型指定されたDataSetを使うか、独自に作成しているツールを使って
テーブル構造から自動でエンティティクラスを作成します。

システム開発なら、開発者やSEのスキルを考慮してコーディング規約を考えないと痛い目を見ます。
質問の内容からすると、全体的にスキルは高くなさそうなので、理想を追うより現実的に実現可能な
方法を模索するのが良いと思います。

辛口の回答ですが、参考まで。

> 私ならばインスタンスを構造体として定義してHogeDataクラスに渡します。

構造体は余分なコピーが発生することがあるので、ちょと非効率的。

この場合は、データ格納専用のクラスを用意して DataAccessHogeHoge クラスのメソッドに引き渡せばいいんじゃないかと。

つか、本来なら DataAccessHogeHoge を定義する段階でそういった「データ格納専用クラスの定義」が出てくるべきな希ガス。

> 上記本の中にはデータクラスは、コードの不吉な匂いということで
> 挙げてありますので矛盾するような気がしています。

どういう根拠があって「不吉」なんだろう？

回答はでていると思いますが俺もちょっとだけ

画面に配置されている各種コントロールはその画面クラスのメンバです。
本来これらのコントロールの状態（テキストだったりサイズだったり）は画面クラス内に
隠蔽されるべきです。必要ならアクセサ（get、setメソッド、プロパティを用意すべき）

１の場合、画面コントロールの名前が変更になっただけで回収が必要になります。
また、入力項目がテキストボックスから、コンボボックスに変更となったときも
かなりの本数に修正が必要になります。

画面からは登録データをまとめたエンティティクラスを作成して、DataAcessHogeHogeの
登録メソッドに渡す。
DataAcessHogeHogeは引数でわたってきたエンティティクラスのパラメータを元に
クエリを発行して結果を返す。

この場合、画面クラスはエンティティを作成してメソッドを呼ぶという行為ですみます。
DataAcessHogeHogeの登録メソッドがなにをしていても影響はありません。

DataAcessHogeHogeはエンティティオブジェクトが渡されれば登録処理が行えます。
呼出元が画面だろうが、バッチだろうが関係ありません、エンティティオブジェクトが
わたってくればＯＫになります。

たとえが悪いかもしれませんが、各クラス間のつながり（今回は画面－DataAcessHogeHoge間）
が強くならないようにするのが理想的です。

ただ、小規模で画面が1個、テーブル1個とかなら画面クラスにSQLを直に書いても
メンテナンスは簡単だと思います。（方法は良くないですが）

返答ありがとうございます。

> まず、もう少しわかりやすく書きましょう。
> 設計の話なのでデータソース(DB)が何かによって話は変わると思います。
説明不足すいません。
DBはAcess or SQLServerを検討しています。
今回の目的は業務システムというよりは、今後の為にある程度のパターン
を決めるといった社内の教育の為のサンプル的な位置づけです。

> 1.FormHogeの各コントロールをPublicにしてDataAcessHogeHogeからFormHoge.・・・にて取得する。
> 問題外です。なぜDataAccessからFormのコントロールにアクセスするのですか？
これに関しては、楽だからという感じでしょうか。話し合いをしているメンバは
VB6時代の方が多数です。Formがクラスであるという概念が薄いためではないかと思います。
"なぜですか？"と質問するとVBのいいところだからという答えが返ってきます・・・。
オガシン様の発言の通り、コントロールの状態（テキストだったりサイズだったり）は画面クラス内に
隠蔽されるべきだと考えています。

> 2.DataAcessHogeHogeにデータ取得用のプロパティを準備して渡す
> この中ではこれでしょうか。ただしDataAccessHogeHogeクラスがどんなクラスなのかはわからないですが。

> 3.登録処理の引数として各値を渡す
> 実際の業務システムを開発しているなら、仕様変更に迅速に対応できますか？
> 作りっぱで良いなら問題ないですが。
DataAcessHogeHogeクラスはSQLの発行を行なうクラスです。入力データからSQLを作成して
発行し結果を返します。今回の質問では、ここのFormHoge－DataAcessHogeHoge間のやり取り
に関して、一概にこれがいいということはないと思いますが、パターンとしてよい案がないかと
思い質問したところでした。

>"リファクタリング　プログラミングの体質改善テクニック"
>の中に引数オブジェクトの導入というテクニックが掲載されており
> 誰もがこの本を読んでいるとは限らないので、この手法と言われても回答のしようがありません。
そのままの名称で書いてしまいました。申し訳ありません。
これは、まとめて扱うべき一連の引数群のデータを保持するオブジェクトを作成して渡すという方法です。
皆様が言われている登録データをまとめたエンティティクラスということになると思います。

> どういう根拠があって「不吉」なんだろう？

以下本文より抜粋
"アクセサしか持たないクラスは、オブジェクト指向の利点を真に活かしていない無意味なクラス"
とあります。ただ、このアクセサを使用している箇所を探し、メソッドをこのクラスに移動できないかを
検討すべきとの内容です。本書をよく読みもう少し勉強したいとおもいます。

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

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

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

Re[2]: DB更新データの渡し方について

過去ログには書き込み不可