DataGridViewの真髄：CellFormattingとCellParsingによる「表示」と「型」の完全分離
多くの開発者が、Windows Forms（WinForms）の`DataGridView`を扱う際、致命的な設計ミスを犯す。それは、「ユーザーが見ている文字列」と「データソースが保持すべき型」の境界線を曖昧にすることだ。
「入力された値を`String`として保持し、表示する時に無理やり書式を整える」「入力チェックを`CellValueChanged`で行い、型変換の例外を場当たり的にキャッチする」――このような実装は、レガシーシステムの保守性を著しく低下させ、大規模データにおけるパフォーマンス劣化と、データ整合性の崩壊を招く。
プロフェッショナルなアーキテクトが取るべき戦略はただ一つ。`CellFormatting`による「視覚的表現の制御」と、`CellParsing`による「意味論的変換」を完全に分離することである。
本稿では、和暦や特殊な通貨書式といった、エンタープライズ領域で不可避な要件を、極めて低負荷かつ堅牢に実装するための極限の知見を伝授する。
1. 概念の峻別：Formatting vs Parsing
まず、我々が制御すべき二つのイベントの役割を、コンピュータサイエンスの観点から再定義する。
CellFormatting：Viewの責務
`CellFormatting`は、データソースから取得された「生の値（Raw Value）」を、ユーザーに提示するための「表示用文字列」へと変換するプロセスである。ここではデータソースの値は一切書き換えてはならない。あくまで「見せ方」のレイヤーである。
CellParsing：Modelへの橋渡し
`CellParsing`は、ユーザーが入力した「表示用文字列」を、データソースが受け入れ可能な「型（Typed Value）」へと逆変換するプロセスである。ここで変換に失敗することは、入力の不正を意味する。
この分離ができていないコードは、UIの表示ロジックとビジネスロジックが密結合しており、ユニットテストすら不可能な「スパゲッティ・コード」へと変貌する。
2. 実装の極致：和暦と特殊通貨のハンドリング
以下に、シニアエンジニアが実戦投入すべき、堅牢な実装パターンを示す。ここでは、`DateTime`型を「和暦」で表示し、`Decimal`型を「特殊な通貨記号」で入力・表示する例を挙げる。
“`vb.net
Imports System.Globalization
”’
”’
Public Class AdvancedGridHandler
‘ 書式設定用のインスタンスは、イベント内での頻繁な生成を避け、
‘ メモリの断片化（GCの負荷）を抑えるためにフィールドとして保持する。
Private ReadOnly _japaneseCulture As CultureInfo = New CultureInfo(“ja-JP”)
Private ReadOnly _currencyFormat As String = “C2″ ‘ 通貨書式
”’
”’
Public Sub OnCellFormatting(sender As Object, e As DataGridViewCellFormattingEventArgs)
‘ インデックスの境界チェックは、描画イベントにおける定石である
If e.RowIndex < 0 OrElse e.ColumnIndex < 0 Then Return
' 特定の列（例：日付列、金額列）に対してのみロジックを適用
Select Case e.ColumnIndex
Case 0 ' 日付列 (DateTime型を想定)
If e.Value IsNot Nothing AndAlso Not IsDBNull(e.Value) Then
Dim dt As DateTime
If DateTime.TryParse(e.Value.ToString(), dt) Then
' 和暦での表示。ここで直接e.Valueを書き換えてはならない。
' e.FormattedValueに代入することで、描画時のみ書式を適用する。
e.FormattedValue = dt.ToString("ggge年M月d日", _japaneseCulture)
End If
End If
Case 1 ' 金額列 (Decimal型を想定)
If e.Value IsNot Nothing AndAlso Not IsDBNull(e.Value) Then
Dim decVal As Decimal
If Decimal.TryParse(e.Value.ToString(), NumberStyles.Any, _japaneseCulture, decVal) Then
' 通貨記号付きの表示
e.FormattedValue = decVal.ToString(_currencyFormat, _japaneseCulture)
End If
End If
End Select
End Sub
'''
”’
Public Sub OnCellParsing(sender As Object, e As DataGridViewCellParsingEventArgs)
‘ 入力値がNothingの場合は、変換をスキップ
If e.Value Is Nothing OrElse IsDBNull(e.Value) Then Return
Select Case e.ColumnIndex
Case 0 ‘ 日付列：和暦文字列からDateTimeへの変換
Dim input As String = e.Value.ToString()
Dim parsedDate As DateTime
‘ 和暦のパースを試みる。失敗した場合は、Parsingを中断し、
‘ 元の文字列をセルに残すことで、ユーザーに修正を促す。
If DateTime.TryParseExact(input, “ggge年M月d日”, _japaneseCulture, DateTimeStyles.None, parsedDate) Then
e.Value = parsedDate
e.ParsingApplied = True ‘ 変換成功を通知
End If
Case 1 ‘ 金額列：通貨形式文字列からDecimalへの変換
Dim input As String = e.Value.ToString()
Dim parsedDecimal As Decimal
‘ 通貨記号やカンマを除去し、純粋な数値としてパース
If Decimal.TryParse(input, NumberStyles.Currency, _japaneseCulture, parsedDecimal) Then
e.Value = parsedDecimal
e.ParsingApplied = True ‘ 変換成功を通知
End If
End Select
End Sub
End Class
“`
3. アーキテクトの視点：パフォーマンスとメモリ管理
この実装において、私が最も注視しているのは「イベントの発生頻度」である。
`CellFormatting`は、ユーザーがスクロールするたび、あるいはセルを選択するたびに、凄まじい頻度で呼び出される。ここで、`New CultureInfo(…)`や`New StringFormat(…)`といったオブジェクトのインスタンス化を繰り返すことは、断じて許されない。
メモリ圧迫の回避（GC Pressure）
短寿命なオブジェクトの大量生成は、Managed Heapを汚染し、頻繁なGarbage Collection (GC) を引き起こす。これはUIスレッドの停止（マイクロスタッター）を招き、ユーザー体験を著しく損なう。
必ず、書式オブジェクトはクラスレベルのフィールドとして再利用（キャッシュ）せよ。
型安全性の確保
`e.Value`に代入する値は、必ずデータソース（DataTableやList(Of T)）の型と一致していなければならない。`CellParsing`で`String`をそのまま`e.Value`に渡してしまうと、後続のデータバインディング処理で`InvalidCastException`を誘発する。
4. 究極のバリデーション戦略
`CellParsing`は「型」の変換に責任を持つが、「値の妥当性（ビジネスルール）」には責任を持たない。
例えば、「日付は未来であってはならない」というルールがある場合、それは`CellParsing`ではなく、`CellValidating`イベントで行うべきである。
1. `CellParsing`: 「これは日付か？」を判定。
2. `CellValidating`: 「その日付は業務的に正しいか？」を判定。
この二段構えの防御策こそが、堅牢なエンタープライズ・アプリケーションを構築するための鉄則である。
結言
Windows Formsはレガシーな技術と揶揄されることもあるが、その内部構造を正しく理解し、イベント駆動のライフサイクルを掌握すれば、これほどまでに強力で制御しやすいフレームワークは他にない。
`CellFormatting`で「美」を、`CellParsing`で「真実（型）」を。
この分離を徹底すること。それこそが、数年、あるいは数十年使い続けられるシステムを設計するための、エンジニアとしての矜持である。
