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

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

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

Re[3]: フォーム内関数とクラス化の分けについて

分類:[設計/仕様]　

あえて、今回は初心者ｗなのでご教示ください。

じゃんぬねっとさんのサイト内から引用
>フォームはメソッドなどにアクセス修飾子が設定できますのでクラスであると言えます。(カプセル化の概念)
>フォームがクラスということは、外部からフォーム内の GUI に関与してはいけないことになります。
>フォーム外で GUI に関する処理を記述するのは、カプセル化の概念を壊していることに他なりません。
>逆に言えば、フォームで処理を記述する時は必ず GUI の処理であるべきです。
>ビジネスロジックは、クラスモジュール (標準モジュール) で、GUI の処理はフォームでやるのが定石です。
http://jeanne.wankuma.com/tips/vb6/rule/vb6oop.html

業務アプリケーション内の機能でよくあるものとして、請求明細書印刷があります。
今回は例として簡易的に書いてます。

■請求明細書印刷
仕様としては、
入力した請求年月を元にＤＢから受注テーブルと売上テーブルを参照して
請求先毎にグループ化して印刷する

画面には、下記の３つのコントロール
・請求年月の日付コントロール
・実行ボタン
・レポートコントロール(レポートはデザイン済み)

ＤＢにアクセスする処理はクラスライブラリにて用意されている。

処理としては、
実行ボタンのクリックイベントにて
・請求年月の入力チェック
・指定された請求年月を条件にSQL句を生成して、
　レポートコントロールのデータソースに渡す
・レポートコントロールをプレビューする

現状として、特に汎用的に使うこともないので、クラス化などせず
全てフォーム内関数と定義しています。
(請求年月の入力チェックとSQL句を生成を関数化、残りは実行ボタンのクリック内に記述)

■質問
あえてクラス化するまでもないと思われるものでも、ビジネスロジックなんだから、
別途クラス化した方がいいのでしょうか？

今回の例としては、SQL句を生成くらいなのかも知れませんが･･･

別に無理にクラス化しなくてもいいのかなー
どの程度でクラス化すればいいもんなんでしょうかね。

■No20945 (やじゅさん) に返信
私の嗜好からいいますと、ビジネスロジックは専用のクラスで定義した方がいいと思います。
例の様な場合、フォーム内に実装することを積極的に否定することは出来ませんが、かと言って積極的に肯定することも出来ません。
でも将来性を考えると、表示層の変更が生じた場合（WPFとかWebFormとか）場合作業が面倒になりますし、GUIだけ複数の役割を担うことになったら開発現場に混乱をもたらす場合もありえると思います。

帳票だとインターフェイスで共通的な初期化と後始末をすることが多いです。
個々の検証的な処理は Form に実装していても良いのではないでしょうか。
私も汎用性のない固有なチェックは静的メソッドに書くことがあります。

■No20945 (やじゅさん) に返信

こんにちは。たまたま帳票出力の例なのかも知れませんが、業務アプリケーションで帳票がひとつだけという
ことはほぼないと思いますので、帳票のベースクラスを作って（プリンタの設定やプレビュー画面の設定等）
請求明細書等の個別の帳票はその派生クラスで作ったりするのではないでしょうか。
この場合、個々のレポートデザインや、請求年月等の独自メンバは派生クラスが持つことになるかと思います。
請求年月のチェックも請求明細書クラスが持っていいのではないでしょうか。
（そのチェック結果をメッセージボックスに出すかどうかはGUI次第）
最初は単独画面からだけ出力していたが、後でバッチからも出力するようになったとかありませんか？

結構好みの問題に分かれる気がしないでもないですが、
私だったらこうするという意味で。

帳票出力部分をクラス化して、
SQL生成部分をクラス化して、
フォームは、入力チェックだけにすると思います。

帳票の出力形式が色々あると思うので、なんともいえませんが。
(エクセル使ったり、サードパーティ製のレポート出力機能を使ったりという意味で。)

レポート出力がある程度基底クラスで、出力ファイルの指定などができ、
共通かできる部分があるなら、ファクトリクラスで、インスタンスの作成までさせます。

ファイルの指定や、指定する部分が多くて、複雑化するなら、ついでにビルドクラスまで
作成しておきます。

ついでに、SQL句の生成部分は、帳票出力クラス側に集約してしまうかもしれません。
DB問い合わせとも一緒に持たせてしまって。

レポート出力画面が複数ある事を考えています。

ただ、その画面でしか、帳票を出力しないのであれば、どう作ってもいいと思います。

他画面があり、その他帳票出力画面があるのであれば、それと同様のつくりにするべきだと思われます。

# もしイメージが違っていたら申し訳ないですorz

回答頂いたみなさん、ありがとうございます。
大変、参考になりました。

「静的メソッド」ってキーワードが私の頭から出てこなかった、まだまだだな

ビジネスロジックはやはり専用のクラスで定義した方がよさそうですね。

通りすがりさんの回答である
>業務アプリケーションで帳票がひとつだけという
>ことはほぼないと思いますので、帳票のベースクラスを作って（プリンタの設定やプレビュー画面の設定等）
>請求明細書等の個別の帳票はその派生クラスで作ったりするのではないでしょうか。

じゅでさんの回答である
>帳票出力部分をクラス化して、
>SQL句の生成部分は帳票出力クラス側に集約してしまうかもしれません。
>フォームは、入力チェックだけにする

今回のプロジェクトではフォーム画面はベースクラスを作っていたのですが、
帳票のベースクラスに関しては作らなかったんです。
本来は作るべきでしたね、次回のプロジェクトではそのようにしてみます。

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

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

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

Re[3]: フォーム内関数とクラス化の分けについて

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