Folks, I get the impression that the DataSet and its child classes classes are falling out of favour, is that true? However, I personally find them to be very convenient and full-featured for apps of all sizes (but I don't expose them to the outside world of course and my discussion here is only about private use). What I like about DataView and DataRow are the huge number of interfaces they support, and for me the most important features are these:
1. When bound to a grid you get bi-directional sorting with no code at all. 2. They supports SQL-like filter expressions (Foo Like '%bar%') AND (FooId > 666) for example, and applying these filters is blazingly fast. 3. IEditableObject in DataRowView gives begin/end edit semantics. While coding lots of Entity Framework 4 over the last several weeks I often have to materialize a collection of entities and send them up to the UI for display in grids or pickers. The EF4 context only allows materializing T[] arrays or List<T> of entities, and these are woeful compared to DataView and DataRow, they don't any of the three lovely features listed above. I have resorted to converting my EF4 query results from raw DbDataRecord back to DataRow so I get all the functionality back. Why do I have to do this workaround? Am I missing some other technique? Note, the entities and collections created by netTiers support all the interfaces that the System.Data classes do, so it's only after migrating to EF4 that I'm hitting this irritation. It seems that I'm taking a step backwards with EF4 entities and hence doing stupid workarounds like converting to System.Data objects. I'm told there is an MSDN EF4 discussion group, so I'll ask about this in there once I find it and get in. Greg
