A DataGrid doesn’t know anything about data tables.
A DataGrid shows the values stored on a list of dictionaries.
The list doesn’t need to be a list. It can be any object that can be iterated like a list. A SearchIterator object created by searching a data table can be iterated, so it can be used by a DataGrid.
A dictionary doesn’t need to be a dictionary. It can be any object with key/value pairs. A Row object returned by iterating a SearchIterator has key/value pairs (one key per column), so it will work.
The DataGrid itself is not going to write back anything, because all it does is rendering stuff, not editing it. But if will assign each dictionary (or dictionary-like) object from its list (or list-like) to the item of its template form, and the template form could have controls that will change the values of the dictionary keys.
I hope that clarifies what a DataGrid does.
Now we can focus on the SearchIterator and Row objects. A Row object is like a dictionary on steroids: it can be iterated and return values to be shown in the UI just like any dictionary, but when you (or any component or any line of code or whatever) assign a new value to a key, it will update the column of the row its original value was read from. And it will do this whether it is on the client or on the server, pretty cool!
I rarely use DataGrids to show data from tables. I either build lists of dictionaries, or, in more complex apps, I create my own classes to interact with DataGrids. For example the class Shipment can be iterated just like a list, and each returned item is an instance of the class Crate which can be used just like a dictionary.