Greg >> "System.Data classes is that you have to write tedious >> ADO.NET<http://ado.net/> code to do all the CRUD"
What about the data adapter.Update command - it does it all for you. Regards ..... Mark Jarzebowski Director Software Engineering Business Model Systems (Victoria) Pty Ltd Kew Victoria www.bms.com.au On Thu, Dec 3, 2009 at 8:57 PM, Greg Keogh <[email protected]> wrote: > Kirsten, lots of discussion about this recently. I like the DataSet, > DataTable and DataRow classes (especially XSD generated strongly typed ones) > for relatively simple apps, they’re easy to use and have an almost textbook > neatness about them. But when things get big and serious, they just can’t > compete with entity classes from frameworks like netTiers and NHiberate > which raise the level of abstraction. > > > > I use DataSet a lot for small apps, but would never use them in anger in > big apps. The worst things about the System.Data classes is that you have to > write tedious ADO.NET code to do all the CRUD. There is no “natural” and > convenient way to say “write all the changed rows and their joined rows back > to the DB”. I’m still using a licensed netTiers + CodeSmith after years of > trying to find something to replace it (including a failed dance with EF). > > > > The trouble is, there’s too much choice in the entity framework arena. > Which one? The latest MSDN magazine arrived in the letterbox yesterday, and > I see there’s a dense 5 page article titled “Building N-Tier Apps with EF4”, > so more choice and more confusion. > > > > Greg >
