k2bumper - I agree that ReadXML and WriteXML are g...

2008-11-21T11:18:00.000-07:00

k2bumper - I agree that ReadXML and WriteXML are great methods off of Datasets. It does make it easy to serialize and pass Datasets around. However, I believe you could serialize and pass the objects from the EF as long as both applications know the type being used in the XML. It would take some work, but I bet you'd be surprised how easy it is. Also, take a look at ADO.NET Data Services (Formally know as Astoria). This gives you an easy way to pass your EF data as XML through a REST based service.

I really like your post. I think you hit on some ...

2008-11-21T07:21:00.000-07:00

I really like your post. I think you hit on some great points. One thing that seems a bit harder to do with the EF and Linq to SQL is the ease of serialization. I long for the time when I can do .GetXML() on an EF object. That was very simple with datasets.

Actually, if your organization dictates that every...

2008-08-04T21:05:00.000-07:00

Actually, if your organization dictates that everything has to go through Stored procedures, Linq to SQL is awkward to work with and much of the benefits of using Linq to SQL are gone, like DataContext automatically tracking changes and automatic optimistic concurrency.

Comparing Linq to SQL with TableAdapter, TableAdapter is much more productive than Linq to SQL.

1. TableAdapter and related utilities make programming against stored procedure much easier, code for sorting, paging etc are automatically generated while using Linq to SQL, you have to write a lot of code for those common tasks.

2. It's recommended that if you want to implement clean tiered solution, don't return IQuery&ltT&gt, instead IEnumerable&ltT&gt, which automatically downgrade your data access from Linq to SQL to Sql to objects.

3. Using IQuery&ltT&gt invokes translating IQuery to T-SQL, which is a performance hit.

4. Object orientation purists sometimes kill performance. Sometimes, it's better to think data as tables and rows rather than objects. Business is about data for the most part. You can express your data as objects, but in the end, the data are persisted in tables as rows. The great sin of ORM is duplicating effort to cache data. RDMS does a great job in managing most used data in memory cache by doing all sorts of amazing jobs, read-ahead, checkpoint, etc; ORM then comes in and do the same, demanding you work with their copy of data in memory. More often than not it's a waste of resources and sometimes create unexpected and strange behaviors. No longer can you know where your changes are. Changes are managed by ORM now. And for most business applications, you are better to save your data to the database as soon as possible, instead leaving those changes in memory and later commit them. I often like to compare the data objects with the game character objects. They are different. When you are playing game, all those characters are really alive; they have to be ready to respond your click or key punches; I would like to call them live objects. On the other hand, data objects are mostly dead after they are retrieved from the database and presented to the user. Users work on those data through forms (fields, lists, etc).

Users are not working on data objects directly in the way we play computer games. Once you can see the difference between data objects and game character objects, then it really doesn't make sense to make your data objects alive in memory all the time and waste your time and resources to manage their life cycle. I heard a lot of horrible stories about ORM/Java, etc. And currently I am working on converting a Java/Hibernet project to .Net because the Java/Hibernet app is ridiculously slow to the point you just want to smash your computer to pieces or jump out of the window :)

By the way, Entity Framework is built on top of ADO.NET, so ADO.NET will not go away. But I agree with you that classic ADO.NET type of programming should not be used. Best approach at this point is to use typed datasets and tableadapter.

2008-08-04T13:05:00.000-07:00

This comment has been removed by the author.

Comments on Ben H Blog - Keep it Simple, Then Refactor.: Are ADO.NET Datasets dead?

k2bumper - I agree that ReadXML and WriteXML are g...

I really like your post. I think you hit on some ...

Actually, if your organization dictates that every...