Windows Formsの呪縛から脱却せよ：VB.NETで極める `INotifyPropertyChanged` の実務実装とクリーン設計
開発現場でこんなコードを見たことはないだろうか。
‘ 【アンチパターン】UIとビジネスロジックが癒着した悪夢のコード
Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
‘ データベースを更新
CustomerDao.Update(Me.txtCustomerName.Text, Me.txtEmail.Text)
‘ ご丁寧にUIのラベルを手動で書き換える
Me.lblStatus.Text = “保存完了しました”
Me.lblLastUpdate.Text = DateTime.Now.ToString(“yyyy/MM/dd HH:mm:ss”)
Me.panelHeader.BackColor = Color.LightGreen
End Sub
画面の項目が増えるたびに、コントロールのプロパティを直接いじくり回すコード。これは一見して動くように見えるが、保守フェーズに入った途端にバグの温床となる。仕様変更で「保存完了時に別のコントロールも連動させたい」となった瞬間、コードベースはスパゲッティと化すのだ。
今回は、VB.NET（Windows Forms）におけるデータバインディングのポテンシャルを極限まで引き出し、「データモデルの変更が、自動的にUIへ伝播する」クリーンなアーキテクチャを構築する極意を伝授する。
—
なぜ手動でのUI更新は悪なのか？
業務アプリケーションの開発において、データ（状態）とビュー（見た目）の同期は永遠の課題だ。
手動でUIを更新するアプローチの何が問題か。それは、「関心の分離（Separation of Concerns）」の原則に完全に逆行している点にある。ビジネスロジックやデータ保持クラスが、UIコントロール（`TextBox`や`Label`）の存在を知っている状態は、単体テストを困難にし、レイアウト変更に対する耐性を著しく奪う。
真にスケーラブルな設計とはこうだ：
1. データモデルは、自身の値が変わったことだけを周囲に伝える（「俺が変わったぞ」と叫ぶ）。
2. UIコントロールは、データモデルを監視し、勝手に自身の表示を更新する。
この仕組みのコアとなるのが、`.NET`が提供する `System.ComponentModel.INotifyPropertyChanged` インターフェイスである。
—
実装の核心：`INotifyPropertyChanged` を網羅した基底クラスの設計
毎回すべてのプロパティでイベントを発火させるボイラープレート（定型コード）を書くのは、エンジニアの労力の無駄遣いだ。実務では、通知ロジックをカプセル化された基底クラス（ViewModel / Modelのベース）を1つ用意することから始める。
以下のコードを見てほしい。VB.NET特有の構文を駆使し、スマートかつ堅牢に実装したプロダクションコードだ。
Imports System.ComponentModel
Imports System.Runtime.CompilerServices
Namespace ViewModels
‘
‘
Public MustInherit Class NotificationObject
Implements INotifyPropertyChanged
‘ プロパティ値が変更された際に発生するイベント
Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged
‘
‘
‘
‘ バッキングフィールドへの参照
‘ 新しい値
‘ プロパティ名（CallerMemberNameにより自動取得）
‘
Protected Function SetProperty(Of T)(ByRef field As T, value As T,
‘ 値に変更がない場合は何もしない（無限ループや無駄な描画を防ぐ最適化）
If Object.Equals(field, value) Then
Return False
End If
field = value
Me.OnPropertyChanged(propertyName)
Return True
End Function
‘
‘
Protected Overridable Sub OnPropertyChanged(
RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propertyName))
End Sub
End Class
End Namespace
アーキテクチャの解説：なぜこの実装なのか？
1. `CallerMemberName` 属性の活用: C#ではお馴染みのこの属性はVB.NET（.NET Framework 4.5以降 / .NET Core以降）でも健在だ。これにより、`OnPropertyChanged(“CustomerName”)` のように手動で文字列を渡す必要がなくなる。「プロパティ名のリファクタリング漏れによるバグ」をコンパイルレベルで完全に根絶できる。
2. 同値チェックによるパフォーマンス最適化: `Object.Equals(field, value)` により、同じ値が代入された場合の無駄なイベント発火をシャットアウトする。これは大量のデータを扱う業務アプリにおいて、UIのフリーズを防ぐための必須要件だ。
—
実務モデルへの適用：データベース連携を見据えたエンティティの実装
では、先ほどの基底クラスを継承した実際のデータモデル（顧客情報ViewModel）を作成しよう。DBから取得したデータをここにマッピングし、画面とバインドする。
Imports ViewModels
Namespace Models
Public Class CustomerViewModel
Inherits NotificationObject
‘ バッキングフィールド
Private _id As Integer
Private _name As String
Private _isModified As Boolean
‘
‘
Public Property Id As Integer
Get
Return _id
Get
Set(value As Integer)
SetProperty(_id, value)
End Set
End Property
‘
‘
Public Property Name As String
Get
Return _name
Get
Set(value As String)
If SetProperty(_name, value) Then
‘ 値が変更されたら、連動して別のフラグも立てるようなビジネスロジックもここに記述可能
Me.IsModified = True
End If
End Set
End Property
‘
‘
Public Property IsModified As Boolean
Get
Return _isModified
Get
Set(value As Boolean)
SetProperty(_isModified, value)
End Set
End Property
End Class
End Namespace
—
Windows Forms フォーム側でのデータバインディング構築
ここからが魔法の瞬間だ。Windows Formsであっても、`INotifyPropertyChanged` を実装したオブジェクトであれば、強力なデータバインディングの恩恵を受けることができる。
フォームのコードビハインドは、極限までシンプルになる。
Imports Models
Public Class CustomerForm
‘ 操作対象のデータモデル
Private _currentCustomer As CustomerViewModel
Private Sub CustomerForm_Load(sender As Object, e As EventArgs) Handles MyBase.Load
‘ 1. モデルの初期化（実務ではここでDAOやRepositoryからデータを取得してバインドする）
_currentCustomer = New CustomerViewModelWithDummyData()
‘ 2. コントロールとモデルのプロパティをバインドする
‘ 第1引数: バインド先のプロパティ名 (“Text”)
‘ 第2引数: データソースのオブジェクト
‘ 第3引数: データソースのプロパティ名 (“Name”)
‘ 第4引数: 変更を即時反映するかどうか (False = フォーマット時, True = 入力即時)
Me.txtName.DataBindings.Add(“Text”, _currentCustomer, “Name”, True, DataSourceUpdateMode.OnPropertyChanged)
Me.lblId.DataBindings.Add(“Text”, _currentCustomer, “Id”)
‘ 変更フラグに連動して保存ボタンの有効/無効を切り替える例
Me.btnSave.DataBindings.Add(“Enabled”, _currentCustomer, “IsModified”)
End Sub
‘ ダミーデータ生成（実務ではDB/APIから取得）
Private Function GetCustomerFromDatabase() As CustomerViewModel
Return New CustomerViewModel() With {
.Id = 1001,
.Name = “株式会社 帝国ロジスティクス”,
.IsModified = False
}
End Function
Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
‘ UIのコントロールを一切触る必要はない。
‘ モデルから直接最新の値を取り出してデータベースへ永続化する。
Dim repo As New CustomerRepository()
repo.Save(_currentCustomer.Id, _currentCustomer.Name)
‘ 永続化成功後、フラグをリセット
_currentCustomer.IsModified = False
MessageBox.Show(“保存が完了しました。”, “通知”, MessageBoxButtons.OK, MessageBoxIcon.Information)
End Sub
End Class
この実装において、`TextBox` に文字を入力するたびに `CustomerViewModel.Name` が更新され、それに連動して `IsModified` が `True` になり、イベントドリブンで `btnSave` の `Enabled` プロパティが自動的に `True` に切り替わる。UIを操作するコードは1行たりとも書いていない。
—
ファイル・データベース連携時の注意点とベストプラクティス
現場でこの設計を導入する際、以下の罠に注意してほしい。
1. スレッド境界の壁（Cross-Thread操作の例外）
バックグラウンドスレッド（`Task.Run` や `BackgroundWorker` など）でDBからデータを取得し、それを直接ViewModelに代入してプロパティを変更した場合、UIスレッド以外からの変更通知イベント発火となり、Windows Formsでは例外（あるいは想定外の描画バグ）が発生する。
- 対策: データ取得は非同期で行い、UIスレッドへコンテキストを戻してからモデルのプロパティを更新すること。または、同期コンテキスト（`SynchronizationContext`）をキャプチャしてイベントをマーシャリングする仕組みを基底クラスに組み込むこと。
2. ガベージコレクション（GC）とメモリリークの罠
Windows Formsの `DataBindings.Add` は、データソース側（今回の場合は `CustomerViewModel`）に強参照を保持するケースがある。長期間起動し続ける業務アプリのメイン画面などで、フォームを開閉するたびにメモリリークを起こす原因になり得る。
- 対策: フォームを破棄する際には必ず `DataBindings.Clear()` を呼ぶか、`.NET` のイベント購読解除のライフサイクルを意識した設計にする。
—
結論：コードの「散らかり」を архитек (アーキテクチャ) で制す
「動けばいい」というゼロ年代のスパゲッティコードから脱却し、保守性・拡張性の高いモダンなVB.NETアプリケーションを構築するためには、フレームワークの機能を正しく理解し、責務を分離することが絶対条件だ。
`INotifyPropertyChanged` の導入は、最初は少しボイラープレートが増えるように感じるかもしれない。しかし、プロジェクトが巨大化し、要件変更の嵐に晒されたとき、「UIの数値を手動で書き換えるコードを1行も書かなくてよい」という事実が、どれほど開発チームを救うか、すぐに実感できるはずだ。
プロフェッショナルなエンジニアたるもの、コードの美しさと堅牢さに妥協してはならない。今日のその設計が、明日のあなたとチームの残業時間をゼロにするのだから。
