ASP.NET 2.0 databinding, 'stateful' entities and Atlas

If you read about the data binding support in ASP.NET 2.0, it always says that is designed for the natural stateless nature of the web, which basically means that each time I update something in the page, it's persisted to the database.v

I was concerned about this, because most of the interesting CRUD scenarios in DeKlarit applications are hierarchical DataSets, like an Order, and it is not an option to add an Order Line to the database each time a user adds an Order Line in the web page. I need to have the whole order, validate it, save it in a transaction, etc.

One of my goals in the PDC was to find out if there was a way to build this with the current data sources or not.

The only way to do it is to use ObjectDataSource, and make the Update(<field list>) method that the ObjectDataSource calls, update a DataSet row. This means that for each DataSet, you need to write a class that will be the adapter between the datasource and your class.

This also applies to standard objects. If you have an Order class and you want to add a line, you need to do the same, create an adapter class that loads the data from the datasource to the class.

IMHO this sucks. The good news for DataSet users is that it's possible to write a generic DataSource (let's say a 'DataSetDataSource') that you can bind to any DataSet and make it work the way I want. If you want to do it for objects, it's also possible but you'll need to use reflection to set fields in the instances and probably make some assumptions on the class' structure.

In the 'Ask the experts' session, I asked some PMs in the ASP.NET team about this. Basically the answer was that if I kept the DataSet in the session my apps would not scale, as keeping state in the server does not scale. My reply was that a DataSet was not different than a standard class, so this problem existed anyway. The problem is you need to keep state somewhere (ViewState, session, database). As I also need to track changes, DataSets looked good, but it applies to any 'track change artifact'.

So, I suggested that I could use the ViewState, and the answer I got was that if I keep the DataSet in the ViewState then the changes will be lost. I could not understand why, but I was not in position to debate it. I later tried it, and that's actually not true. Keeping the DataSet in the ViewState makes the ViewState big, but it does keep the changes and the original data correctly.

To make things worse, in the Atlas.NET presentation they showed that they needed to build a 'dataset like' class with JavaScript to track changes in the client. To talk to the server, you need a class that implements methods like 'Update'/'Insert'/'Delete', etc, and the Atlas infrastructure will call it. They won't call each method from the client, they will stream all the changes in one roundtrip and call the methods in the server. First question, why don't serialize it to a DataSet?? Second, how will they manage transactions, validations, etc?

As a general impression, it looked to me that the ASP.NET team did not understand the real-world issues we face when building database-based applications, and that they also don't know how the DataSet works and why is it there.

ASP.NET 2.0 databinding is great for read-only data, but is lacking when you want to update it.