Hi, At the moment, at work, there are three projects running and the one that I support.
Legacy app. Uses datasets everywhere. Pros. Very fast, readonly application. Cons. Impossible to debug / modify, data is often loaded behind the scenes which cause temporary database table locks .Net 4 with EF Pros. Developpers very engaged with the project, lots of sexy tech. Cons It's been in development now for 6 months and very little visible progress has been made. One screen is done with what ammonts to a single select * .Net 3.5. Nhibernate Pros Works very well, transparent for ui developpers. Cons Misconceptions with heriacical classes in nhibernate has made it impossible to modify the data source. we have hundreds of work arounds to solve the inheritance problems. .Net 3.5 using datasets mapped to objects. Pros. Very easy to use, easy to maintain and add functionality. Cons. The code base is easily twice as big as the other projects Personally, if I was doing a new website. I would use nhibernate Web interface for existing database, ef. Stand alone Application, ado datasets and map to objects. Davy. "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml -----Original Message----- From: "Greg Keogh" <[email protected]> Sender: [email protected] Date: Wed, 20 Jul 2011 17:55:23 To: 'ozDotNet'<[email protected]> Reply-To: ozDotNet <[email protected]> Subject: System.Data classes and List<T> 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
