■21351 / ) |
Re[1]: プログラマの地位って・・・ |
□投稿者/ はつね (803回)-(2008/07/01(Tue) 10:45:40)
|
技術的なところだけ返信します〜。
■No21321 (小春 さん) に返信 > オブジェクト指向のお話をしていたところ、 > FormクラスにSQLを記述するか、それともSQLを記述したクラスを別途分けるか? > それともストアドにするか?なんてことを話していました。 > (基本設計時にクラス設計も取り入れろ!って話してました。) > > 私は経験上、FormクラスにSQLを記述した方がDebugしやすいし、 > バグの箇所もすぐに分かるので、分ける必要がないもの(WebServiceを使用しないもの)に関しては、 > FormクラスにSQLを記述した方がよい!と言い切りました。
オブジェクト指向かどうかは別にして、SQLなどを記述するロジックはFormから分離できるものならば 分離した方が良いと考えています。 つまり、何かを考えるときの基本的な立ち位置は「分離したい」という事です。
そこから、実際に実装するにあたり、 別アセンブリ(またはWEBサービス)→同一アセンブリの中の別クラス→Fromクラスの中のサブプロシージャ(関数) といいう方向で基本から離れる事もあります。 このあたりはケースバイケースですので「開発方針」とした場合は、やっぱり「別アセンブリ化」と して、注釈で基本から離れる場合についてのルール(誰がOKを出すかなど)を書くと思います。
理由は、別アセンブリや別クラスファイルとする事でロジック部分をユニットテストしやすくしたい というのがあります。Formクラス自体をユニットテストする事も可能ですが、別クラスファイルや別 アセンブリになっていた方がやりやすいです。
別にする事のdebugの手間については、Visual Studioのソリューションなどを活用して回避すると いう前提であれば、大変さは軽減できると考えますので、全体の品質を保つという事からすれば、 現時点では、「分離したい」という方針に傾きます。
> 彼の主長として、 > 「顧客の要件をきちんとおさえていたら、大きなシステムでもAccessで動けばいいよ。」 > だそうです。 > 保守性が悪く、拡張性のないものを作りたかったらどうぞ。と心の中でつぶやきました。
Accessで作成するという事が、本当に顧客の要件を満たしているのであれば、それはそれで 正論だと思います。 しかし、往々にしてあるのは顧客の要件ではなく、「Accessだったらオレにもわかるだろう」 だとか「Accessだったら要員いっぱいいるだろう」的な自分の要件が全面に出て採用される 事が多いですね。 多分、スレ主さんは、こういった自分の要件を顧客の要件よりも優先している発言に腹を 立てているのかなと思いました。
|
|