- PR -

業務システムのデザイン

«前のページへ 1|2
投稿者投稿内容
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-05-21 14:44
引用:

未記入さんの書き込み (2006-05-19 18:37) より:
＞SQL 文だけをサブルーチンにしただけで、結局はクラスというものがほとんど登場しないような感じになります。

はい。結局はこうなってきました。
ただSQLを組み立てる際、画面の入力内容を参照するためにサブルーチンの引数にフォームインスタンスを渡すのに抵抗がありました。
でもFormもクラスなので問題ないのしょうか？
画面系は継承やインタフェースなどの恩恵を感じますが
RDB系は従来のVBの方法がベターだということでしょうか？

広い意味での MVC で言うところの、ビューであるフォームと、モデルである RDB は明確に分離したほうが良いと思います。そういう観点から言えば、フォームを引数として渡すのはビューとモデルが近すぎるような気がします。理想的には、フォームなどのビューがなくてもログイン処理や登録処理等のビジネスロジックが動けるような作りになっているのが良いです。フォームを分離できればテストケースを作るのも楽で、テストやデバッグ時にも便利です。

もっとも、
引用:

未記入さんの書き込み (2006-05-19 13:27) より:
ちなみにクラス分けで失敗したパターンは以下のようなものでした。
・ログイン画面より入力した内容をログインManagerクラスのプロパティにセット。
・ログインManagerクラスがRDBから取得したデータをDataTableでログイン画面に戻す。
・ログイン画面よりメインメニューStartクラスのプロパティにユーザー情報をセットする。
・メインメニューStartクラスよりメインメニュー画面を開きプロパティにユーザー情報をセットする。
・メインメニュー画面はユーザー情報プロパティを元にメニューの不可を設定する。
・メインメニュー画面は入力画面Startクラスのプロパティにユーザー情報をセットする。
・入力画面Startクラスは入力画面を開き、プロパティにユーザー情報をセットする。
・入力画面は入力内容を入力画面Managerクラスのプロパティにセットし、RDBに登録する。

画面での入力内容が多いとクラスのプロパティにセットするだけでも非難の嵐でした。

は、わりとそういうことを目指した作りになっているようにも見えます。大きな方針としては悪くないような感じがします。要は、「オブジェクト指向にしなくても今までプログラムを作れて来たのに、なんでわざわざオブジェクト指向にしなければいけないのか？」というありがちな問題が背景に潜んでいるのだろうと推測します。そしてとくに RDB が絡んでくるとこれが顕著になります。RDB があるかぎり避けられないでしょうね。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）