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.


  • The data has to be stored somewhere. A DataSet has the potential of storing a big amount of data. If you store it in session and have a high volumn of users, then your server has to save that to memory (or preferably a session store such as SQL Server, etc) or Viewstate.

    The Viewstate option is a nightmare because it means all the data from the Dataset has to travel to the server and back each time the page is posted back.

    If you're only changing a row on the client side, why not just store the primary key and the changes will be available in the web page via the controls or the GridView controls as an example. Persisting as Dataset via a web application is the wrong road to go down, IMHO.

  • John,

    I'm not just changing a row on the client side. I can have more than one page that is adding/updating/deleting rows to an order (like a shopping cart). I need the old values and I need to know which row was added/deleted/updated.

    This is not only related to a dataset but to any scenario where you need to have a structure with more than one record and then save all of them together.

    So, the state has to be kept somewhere...

  • Andres, I completely agree with you. My experience with the new GridView and data binding in 2.0 has been less than impressive. They dont handle the update scenario very well as all imo. I reverted back to doing it manually they way were doing it before because they didnt bother to think about how to handle readonly properties on objects! :( I think this stems from the fact as you pointed out that not many people on the team must understand real world applications.

Comments have been disabled for this content.