.NETラボ勉強会　2022年1月 「保守性の高いアプリケーション設計について」

1. 保守性の高いアプリケー
ション設計について
株式会社SAKURUG
エンジニアリングユニット
草場 友光
.NET ラボ 2022年1月

2. 自己紹介
• 普段は主にWebFormsアプリ
の保守のお仕事をしてます。
• 古めのシステムが多いので時
代に取り残されぬよう新しい技
術を一つでも入れるよう日々努
力しています。
• tomo_kusaba

3. 宣伝
【VISION】ひとの可能性を開花させる企業であり続ける
VISIONに共感できる仲間募集中。

4. 注意
• 個人の見解・解釈が多分に入っています。
• 見解の相違・事実誤認などありましたらご指摘ください。
• #dotnetlabでtweetすると右側に表示されます

5. 今日の目的
• 注意）今回は最低ラインのところで考えています
• よりよいところを目指すためにはクリーンアーキテクチャなど
を参照してください
• アプリケーション保守目線で保守性のよいアプリケーションを
作るにはどのようなデータのやりとりをすべきか考える
• バッドノウハウを共有し誤りを繰り返さないようにする

6. 主なトピック
• バッドノウハウ
• データオブジェクトの流れについて
• 命名規則について

7. バッドノウハウその1
• DBから取得された値が2次元配列に格納されている
• 画面(aspx)はその2次元配列を直接みてる。。。。
• 配列の何番目に何の項目が入ってるのか設計書もない！
• SQLのSELECT句の何番目はどのカラムかをひたすら確認する
不毛な作業！！
• SELECT句の途中に追加するのはダメ！絶対！

8. バッドノウハウその1図解
select col1,col2,col3,col4 from
table1 where …
col1_1 col2_1 col3_1 col4_1
col1_2
col1_3
col1_4 col4_4
A B C D
col4_1 col2_1 col1_1 col3_1
col4_2
col4_3
col4_4
配列
画面
実際には100カラム近く！

9. バッドノウハウその2
• DBから取得された値が2次元配列に格納されている(複数）
• ロジックで(aspx.cs)別の2次元配列に格納し直して画面に渡し
てる（一つ）
• ？？その1より難読化が進んでないか？？

10. その1，その2まとめ
• データをいれるのに配列を使うとその添字だけでデータを管理
しなくてはいけないのでとても人間でない。
• 何かの連続データ以外を配列に入れるのはやめよう
• Stream以外の可変長のデータも配列に入れるのはやめよう。
• →List<T>を使おう。

11. バッドノウハウその3
• DBアクセスメソッドの引数としてDictionary<string, string>
を使用
• 呼び出し元でKeyの設定が不十分だと例外発生！
• 保守開発時のみならず新規開発時でもこの作りすると大変だよ
ねえ。。。実行時にしか検出できなくて。
• SELECTのWhere句にあたる部分だけならまだしも、Insertだ
と大変！
• なぜ、全カラムをプロパティとするクラスを作らないのか

12. バッドノウハウその3続き
• Dictionary<string, string>のKey側にEnum.ToString()した
ものを設定する仕様？？
• メソッドの中ではEnum.ToString()して読んでいるがそもそも
引数がstringなのだから同じ文字列を引数にしてあげれば
Enumいらない。

13. ノウハウ1
• DBのテーブルごとにテーブルを表すクラスを作る
• クラス名はテーブル名
• プレフィックスをつけておくと区別がつきやすい
• プロパティはカラム
カラム 型
1 col1 number(3)
2 col2 varchar2(10)
3 col3 date
public int col1 {get; set;}
public string col2 {get; set;}
public DateTime col3 {get; set;}

14. ノウハウ2
• 画面を表すクラスを作る
• クラス名は基本画面名（英語名）
• プレフィックスをつけておくとわかりやすい
• プロパティは画面項目に対応（英語名 or 日本語）
• 英語名称をつける場合は一貫性を保つために辞書を作るとよい
• 専門用語など英語名をつけるのが困難な場合日本語プロパティも考慮
• 日本語でプロパティを作っても使うときはVisualStudioのサジェス
トが効くのでどうということはない。
• むしろ、日本人にとってわかりやすい！
• とはいえ、S-JIS範囲程度にしておいた方が無難

15. ノウハウ3
• DBのテーブルを表すオブジェクトと画面を表すオブジェクト
を移し替えるポイントが大抵改修点になる
DB
値の移し替
え 画面
DBオ
ブジェ
クト
画面
オブ
ジェ
クト
データア
クセス
DBオ
ブジェ
クト

16. バッチも同じ
• バッチも考え方は全く同じ
値の移し替
え
DBオ
ブジェ
クト
出力オ
ブジェ
クト
オブジェ
クト化
入力オ
ブジェ
クト
入力
DB
出力

17. なぜこうするか？
• 変更の影響範囲を小さくしたい。
• 一つのオブジェクトの範囲を小さくしたい
• 画面の変更を下の層に持ち込ませたくない
画面
ロジック
データアクセス
データベース
変更頻度 大
変更頻度 小 変更難易度 大
変更難易度 小

18. 効果
• たいていの場合ロジック部分までの改修で納まることが多い
画面
ロジック
データアクセス
データベース
変更頻度 大
変更頻度 小 変更難易度 大
変更難易度 小

19. 効果2
• この図でいくとこの部分
DB
値の移し替
え 画面
DBオ
ブジェ
クト
画面
オブ
ジェ
クト
データア
クセス
DBオ
ブジェ
クト

20. ノウハウ4 命名規則について
• プロジェクトごと命名規則を作ろう！
• 日本語名⇔英語名の対比辞書を作る
• 同じものを表すオブジェクトは同じ名前で
• 似たような意味だけども違うものは違う名前で
名は体を表すように命名しよう

21. ノウハウ4その2
• メソッドの命名について
• プロジェクトで統一感を持たせる
例）
データベースレコードを選択するメソッド：Select[代表テーブル名][機能名]
データベースレコードを更新するメソッド：Update[代表テーブル名][機能名]
データベースレコードを挿入するメソッド：Insert[テーブル名]
データベースレコードを削除するメソッド：Delete[テーブル名]

22. 命名で迷ったら
3章を読みましょう
よい本なので通読をおすすめします

23. おしまい
おしまい