Hi Greg.. I've worked a bit with an open source app called nSurvey ( http://survey.codeplex.com), and it uses the datatables and datasets all the way from DB to UI. However, it's overridden/extended the dataset and data table to make them more like strongly bound types.
I don't know if these are auto generated (netTiers or other) data objects, but there are examples in the "Branch ++ survey-1.2.3.1 ++ Reflector ++ NSurvey BE ++ Votations.NSurvey.Data" project section, and there are examples in the Web App Project (ie. Branch ++ survey-1.2.3.1 ++ Survey WAP ++ NSurveyAdmin ++ UserControls ), files which show how the data is extracted and added to the data objects. The DAL uses the old MS Data Application Block helpers to massage the data to and from the db. As with all models, there's pros and cons, some of which I really noticed were.... PRO - single data object to get data from db to UI in a *relatively* strongly typed manner CONS - a real b!tch to hand code new Data object classes.. CONS - the data objects seemed heavy to use, ie. lots of typing. I personally like using the List<T> for transporting entities.. A fairly simple linq query can be used to sort and/or query the list, and if you're using .Net 4.0, then the TPL extension of ".AsParallel" may add some zip to the sort process. Grant On Wed, Jul 20, 2011 at 5: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**** >
