C#でWinFormアプリを作る場合のコードの別け方

お世話になります。
c#でWinFormアプリを作っているのですが、様々なコントロールのイベント関数や、それに付随する関数、自作のクラスが全てForm.csの中に記述しています。
例えば、下にあるコードのような感じです。
WinFormアプリを作成する場合、このようにForm.csの中に全てのコードを記述するのが一般的なのでしょうか？
Formの構成は、メインとなるForm、そしてボタンを押すと表示されるサブのFormが複数ある感じです。
何か機能毎にファイルを別けたほうがいいのかもしれませんが思いつきません。そのような解説をしているサイトなども見つからずひたすらForm.csに全てを記述して非常に長いコードになっています（サブのFormの機能はそのForm.csに記述しています）。

これで問題ないのでしたらそれでいいのですが、いまいちどう別けたらいいのかわかりません。
どうぞよろしくお願い致します。

Windows10 + VisualStudio2015 C#

C#
1namespace TestForm {
2	public partial class Form_main : Form {
3		// メンバー
4		private int m_foo;
5		private int m_bar;
6		
7		// イニシャライズ
8		public Form_main() {
9			InitializeComponent();
10		}
11		
12		// Formロード後処理
13		private void Form_main(object sender, EventArgs e) {
14			// 省略
15		}
16		
17		/* -------------------------------------------------------- */
18		// コントロールのイベント関数の定義
19		/* -------------------------------------------------------- */
20		// ButtonAを押した場合
21		private void button_A_Click(object sender, EventArgs e) {
22			
23		}
24		
25		// ButtonBを押した場合
26		private void button_B_Click(object sender, EventArgs e) {
27			
28		}
29		
30		// 以下同様にコントロールのイベント関数
31		// ・・・
32		
33		/* -------------------------------------------------------- */
34		// 独自関数の定義
35		/* -------------------------------------------------------- */
36		private void outputConsole(){
37			Console.WrightLine(m_foo);
38		}
39		
40		// 以下同様に独自関数
41		// ・・・
42	}
43	
44	/* -------------------------------------------------------- */
45	// クラス定義
46	/* -------------------------------------------------------- */
47	class Hoge {
48		public int a {get; set;}
49		public int b {get; set;}
50		
51		public int add(int val_a, int val_b){
52			return val_a + val_b;
53		}
54	}
55	
56	// 以下同様にクラスを記述
57	// ・・・
58}
59

行動規範の内容に同意します

回答3件

小規模な開発の場合はフォームに直接記述というのも選択肢のひとつです。
しかし、意外に個人で作るレベルのプログラムでもイベント部分に処理を書いていくと早晩スパゲッティーコードが出来上がります。

私は、Form（画面＝GUI）とService（業務ロジック）で分けて記述するのをオススメします。見た目に関するところと、イベントを受けるところだけはFormに書きますが、その他は全て別のファイル（クラス）に書くようにするという方法です。

イメージとしては「画面がなくても業務ロジック（機能）は全て実行できるように」と考えると、うまく分離できると思います。

投稿2016/09/29 08:27

編集2016/09/29 14:49

Kamata

総合スコア19

退会済みユーザー

2016/09/29 09:28

ありがとうございます。 >しかし、意外に個人で作るレベルのプログラムでもイベント部分に処理を書いていくと早晩スパゲッティーコードが出来上がります。はい、そうなのです・・・。 >イメージとしては「画面がなくても業務ロジック（機能）は全て実行できるように」と考えると、うまく分離できると思います。ああ！わかりやすいですね！そうですね、GUIがなくても実行できるようにするのは大事ですね。そうすると、具体的にはFormクラスの中で別ファイルに定義したクラスのインスタンスを生成して、Form内のイベント関数の中でそのインスタンスのメソッドを実行する感じでしょうか？インスタンスのメンバーにコントロールを渡したりしないといけなそうで、それはそれで複雑になりそうなイメージですが、そういうものなのでしょうか？

Kamata

2016/09/29 14:47 編集

若干手間は増えるのは間違いないです…が、それを補って余りある効果はあると思います。コントロールを渡すのではなく、コントロールの値をセットしたモデル（ViewModel）を作って渡す感じで作ります。コントロール自体に依存してしまうと、Formと切り離せなくなってしまうので。私の作り方は以下のような感じです。 1. 機能毎にServiceクラスを作ります。　 ※難しい処理をする場合はココがモデリングの腕の見せどころです 2. 機能を実行するのに必要なプロパティを持ったViewModelクラスを作ります。 3. Formで機能を実行するイベントが発生した場合、　 ViewModelのプロパティにコントロールの値をセットして、　 ViewModelを引数にしてServiceを呼び出します。 4. 機能の実行結果をFormに返す場合は、ServiceはViewクラスに値を詰めて返します。 5. Formでは、Viewクラスのプロパティから値を取り出してコントロールにセットします。するとFormには、画面遷移とコントロール←→Model間の値のセットのコード以外はあまり書く必要がなくなるというわけです。 FormとServiceの依存性は切れるので、コマンドラインツールのインターフェースを付けたいとか、Web APIにしたいとか、実行結果はファイルに出力したいとか…様々なことが可能になります。 …実際はそこまでシンプルに行くことは稀で、「状態」を持っていたいとかなんとか、色々と考えないといけないことはいっぱい出てきますけれど。

Kamata

2016/09/29 10:15

ちなみに、ファイルはSeviceクラス（業務ロジック）、ViewModelクラス、Viewクラス等々、全部別ファイルにして作ります。数が多い場合は種類毎にフォルダ分けもします。 Formとは全く別フォルダに、まとめて置いておきます。フォームとは関係ないんだと意識付けるためです。（ServiceとViewModelとViewは切り離せないセットになる場合が多いと思います）

退会済みユーザー

2016/10/06 00:25

ありがとうございます！非常にわかりやすいご説明で感謝致します。お答えいただいた内容を参考に切り分けをしてみようと思います。

行動規範の内容に同意します