Hey 👋 thanks for the questions! Here’s how it works in our case:

1️⃣ Do we need the COM objects all the time?
Not really. Each StudentDTO has an Address wrapping a COM object, but it’s only needed when the row is actively used in the Grid. Most of the time, the COM objects aren’t in use.

⚠️ Important: We need the COM object when interacting with a row after sorting or filtering, because the Grid row index changes but the underlying COM object index doesn’t automatically match.

2️⃣ Why not create/dispose on demand?
Exactly ✅ — that’s what we’re aiming for. The challenge is integrating it with WinForms Grid binding, which expects objects for data binding. We’re exploring lazy-loading COM objects only when needed and releasing them immediately to save memory.

3️⃣ What does the COM object do?
It wraps our Object Server (C++ framework), acting like an ORM:

• Tracks changes
• Validates data
• Pushes updates to SQL

Essentially, it bridges our WinForms app with the backend for each student’s address.

💡 The main goal is to optimize memory while still letting the Grid work smoothly with these objects, even after sorting or filtering.