BindingSourceの真髄：UIとデータの「分離」がもたらす極限のアーキテクチャ
多くのVB.NET開発者が、UIコントロールに直接`DataTable`を突っ込み、その結果として「カレント行が取れない」「フィルタリングのたびに再バインドが発生する」といった泥沼のスパゲッティコードに陥っている。
BindingSourceは単なるラッパーではない。これはUIとデータソースの間に介在する「調停者（Mediator）」である。これを掌握することは、Windows Formsアプリケーションにおけるメモリ管理とイベント駆動の秩序を支配することと同義だ。
—
1. なぜBindingSourceを挟むのか：疎結合の哲学
UIコントロール（DataGridView等）にデータを直接流し込むと、UIの寿命とデータの寿命が完全に同期してしまう。これは小規模なツールなら問題ないが、業務システムでは致命的だ。
`BindingSource`を利用することで、以下のメリットが生まれる。
- カレント行の抽象化: `CurrencyManager`を直接触らずに、現在の選択行を安全に追跡できる。
- フィルタリングの透過性: データの物理構造を変えずに、`Filter`プロパティでビューを切り替えられる。
- 双方向同期の自動化: データベースの更新とUIの反映を、手動の再描画なしで完結させる。
—
2. 実装の極意：フィルタリングとメモリの最適化
データベース連携において最も忌避すべきは、検索のたびにクエリを発行してUIをクリアし、再バインドすることだ。これは`Windows API`の描画サイクルを無駄に消費する。
以下は、メモリリークを回避しつつ、高速にフィルタリングを実現するパターンの雛形である。
.net
‘ フォームレベルで保持し、破棄時に確実に解放する
Private WithEvents _bindingSource As New BindingSource()
Private Sub InitializeDataBinding(ByVal data As DataTable)
‘ データソースを設定
_bindingSource.DataSource = data
‘ UIコントロールをバインド
dgvMain.DataSource = _bindingSource
txtSearch.DataBindings.Add(“Text”, _bindingSource, “FilterExpression”, True, DataSourceUpdateMode.OnPropertyChanged)
End Sub
‘ 高速なフィルタリングの実装
Private Sub ApplyFilter(ByVal filterText As String)
‘ フィルタリング適用時、CurrencyManagerの再同期を最小限に抑える
‘ suspend/resumeは不要だが、大量データの場合はUIの描画抑制を考慮せよ
If String.IsNullOrWhiteSpace(filterText) Then
_bindingSource.Filter = Nothing
Else
‘ 検索対象の列に対してエスケープ処理を忘れないこと（SQLインジェクション対策と同じ意識で）
_bindingSource.Filter = String.Format(“ColumnName LIKE ‘%{0}%'”, filterText.Replace(“‘”, “””))
End If
End Sub
‘ フォームクローズ時のメモリ解放は必須
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
If _bindingSource IsNot Nothing Then
_bindingSource.Dispose()
_bindingSource = Nothing
End If
End If
MyBase.Dispose(disposing)
End Sub
—
3. シニアエンジニアが意識すべき「裏側の挙動」
CurrencyManagerの存在を忘れるな
`BindingSource`の背後には必ず`CurrencyManager`が存在する。もし特定の行の値をプログラムから強引に書き換えた際、UIが追従しない場合は`_bindingSource.ResetBindings(False)`を呼び出すのではなく、データソース側の`RowChanged`イベントが適切に発火しているかを確認せよ。不必要な`ResetBindings`は、UIのスクロール位置をリセットさせる最悪の副作用を生む。
大量データ処理のボトルネック
10万件を超えるデータセットを扱う場合、`BindingSource.Filter`はクライアントサイドでのフィルタリングを行うため、パフォーマンスが低下する。その場合は`BindingSource`を捨て、データベース側で`WHERE`句を生成して再取得する方が、メモリ消費効率と応答速度の観点で遥かに優れている。「すべてをクライアントで解決しない」のが、大規模システムにおける鉄則だ。
—
4. レガシー連携：VBAからVB.NETへの橋渡し
もしあなたがVBAからの移行期にあるシステムを担当しているなら、`BindingSource`を「COMインターフェース」の代替と捉えるべきだ。
VBAで苦労した`Recordset`の移動やフィルタリングは、`BindingSource`を使えば`Position`プロパティを操作するだけで済む。
.net
‘ カレント行の移動を検知し、別の詳細フォームへ連動させる
Private Sub _bindingSource_PositionChanged(sender As Object, e As EventArgs) Handles _bindingSource.PositionChanged
Dim currentRow As DataRowView = DirectCast(_bindingSource.Current, DataRowView)
If currentRow IsNot Nothing Then
‘ 詳細情報の同期ロジックをここに記述
UpdateDetailView(currentRow(“ID”))
End If
End Sub
結びに：技術は「楽をする」ためにある
BindingSourceを使いこなすことは、コードを短くすることではない。「UIという不安定な領域」と「データという安定した領域」を分離し、その境界線（境界条件）を管理することである。
VB.NETは、その簡潔な構文ゆえに「とりあえず動くコード」を量産しやすい。しかし、真のエンジニアは、その背後で何が起きているか（メモリの解放順序、イベントの連鎖）を常に視界に入れている。
今日からUIコントロールのプロパティを直接いじるのをやめ、BindingSourceという名の調停者を介在させよ。それだけで、君の書くコードの品質は一段上の次元に到達するはずだ。
