呪縛からの解放：DataSet/DataTableを捨て、軽量POCOによる「次世代データ駆動」へ
VB.NETにおける`DataSet`や`DataTable`は、かつてRAD（高速アプリケーション開発）の象徴だった。しかし、今の時代、それらは「メモリを喰らい尽くす負の遺産」以外の何物でもない。
行単位のメタデータ、変更履歴の追跡（RowState）、型指定のオーバーヘッド……。これらは数万件のレコードを処理するだけで、GC（ガベージコレクション）を頻繁に発動させ、アプリケーションをカクつかせる主犯となる。
今日は、レガシーの呪縛を解き、モダンなPOCO（Plain Old CLR Object）戦略へ移行するための、アーキテクトとしての「回答」を提示する。
—
1. なぜDataSetは「悪」なのか：メモリ空間の非効率性
`DataTable`は、各セルを`object`型として保持する。値型であってもボクシングが発生し、ヒープ領域を激しく断片化させる。さらに、`DataRow`自体が複雑な内部状態管理を行うため、純粋なデータ構造と比較してメモリ消費量は数倍から十数倍に跳ね上がる。
システムのリソースを極限まで絞り出すには、以下の原則を貫く必要がある。
1. 疎結合の追求: データ構造をDBの制約から切り離す。
2. 不変性の確保: 可能な限り`ReadOnly`プロパティを活用する。
3. GCの負荷低減: 短命なオブジェクトを減らし、アロケーションを最小化する。
—
2. 実践：POCOによる軽量データ構造への転換
まずは、データを格納する最小単位の構造を定義する。`DataSet`の代わりに、極めて軽量なクラスを作成する。
‘ 軽量なデータホルダー（POCO）
‘ 構造体(Structure)ではなくクラスを使用し、参照の局所性を考慮する
Public Class SalesRecord
‘ 初期化時に値を確定させる不変的な設計
Public ReadOnly Property Id As Integer
Public ReadOnly Property Amount As Decimal
Public ReadOnly Property Timestamp As DateTime
Public Sub New(id As Integer, amount As Decimal, timestamp As DateTime)
Me.Id = id
Me.Amount = amount
Me.Timestamp = timestamp
End Sub
End Class
3. パフォーマンスを最大化するデータロード戦略
`DataAdapter.Fill(dt)`で一気にメモリを確保する手法は今すぐ捨てろ。LINQ to DataReaderを使い、メモリをストリームとして扱うのが現代の定石だ。
Imports System.Data.SqlClient
Public Function GetSalesData(connectionString As String) As IEnumerable(Of SalesRecord)
Dim results As New List(Of SalesRecord)()
Using conn As New SqlConnection(connectionString)
Dim cmd As New SqlCommand(“SELECT Id, Amount, TransDate FROM Sales”, conn)
conn.Open()
‘ DataReaderを使用してストリーミング読み込み
Using reader As SqlDataReader = cmd.ExecuteReader()
While reader.Read()
‘ 必要な分だけインスタンス化し、メモリ負荷を平準化する
results.Add(New SalesRecord(
reader.GetInt32(0),
reader.GetDecimal(1),
reader.GetDateTime(2)
))
End While
End Using
End Using
Return results
End Function
—
4. レガシー環境でのAPI呼び出しとメモリ解放の真髄
古いシステムでは、Win32 API（`Kernel32.dll`など）を直接叩く機会も多いはずだ。ここで重要なのは、`Marshal`クラスを用いたメモリ管理と、`IDisposable`の徹底的な遵守である。
特に、非マネージメモリを割り当てる際は、以下のパターンを厳守すること。
‘ 非マネージリソースを使用する場合の典型的なDisposableパターン
Public Class NativeBufferWrapper
Implements IDisposable
Private _ptr As IntPtr = IntPtr.Zero
Public Sub New(size As Integer)
‘ 非マネージメモリの確保
_ptr = System.Runtime.InteropServices.Marshal.AllocHGlobal(size)
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
If _ptr <> IntPtr.Zero Then
‘ 明示的な解放を怠ればメモリリークが確定する
System.Runtime.InteropServices.Marshal.FreeHGlobal(_ptr)
_ptr = IntPtr.Zero
End If
GC.SuppressFinalize(Me)
End Sub
End Class
—
5. アーキテクトからの提言：移行のロードマップ
いきなり全システムを書き換えるのは自殺行為だ。まずは「読み取り専用のクエリ」からPOCOへの移行を開始せよ。
- フェーズ1: `DataTable`を返却していたメソッドを、`IEnumerable(Of T)`を返すようにシグネチャを変更する。
- フェーズ2: UIバインディングが必要な箇所のみ、最小限の`BindingList(Of T)`へ変換する。
- フェーズ3: `DataSet`への依存を、`Dapper`のような軽量ORM、あるいは純粋な`DataReader`に置き換える。
最後に
VB.NETという言語は、決して過去の遺物ではない。CLR（Common Language Runtime）の上で動作する以上、C#と遜色ないパフォーマンスを引き出すことは可能だ。
「DataSetが便利だから」という怠惰な思考を捨て、メモリとCPUの挙動を肌で感じろ。コードの行数ではなく、「メモリ上に何が展開されているか」を可視化できた時、君は真のエンジニアとしてシステムを掌握できるはずだ。
妥協なき実装を期待している。
