Ok, who wants to banish Greg? Bags not.
On Wed, Jul 20, 2011 at 3:55 PM, Greg Keogh <[email protected]> wrote:

> 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****
>

Reply via email to