Strongly-typed Datasets in ASP.NET 2.0

Hello,

In ASP.NET 1.1, I followed this data access methodology:

At design time
- Create a strongly typed dataset
- Add this dataset to a form and bind controls to the dataset using
the designer

At run time
- Fill dataset with data on the first load of the page
- Handle all Add/Edit/Delete operations against the in-memory copy
of my dataset
- Persist the dataset between postbacks in session
- Give users the ability to Save or Cancel changes, which either
persists the changes to the database or discards them.

It worked like a charm -- there were only two trips to the database --
in the very beginning and at the very end. In memory manipulations were
very fast. And, more importantly, my productivity was high because I
was able to use design features of the Visual Studio.

It seems that in 2005, if I were to pursue the same methodology, things
would be harder, not easier.

- It appears that the only way to bind a dataset to a gridview is
through the ObjectDataSource. This binds to table adapters, not the
actual dataset, so, the database gets hit on each update.

- DataSource property is gone from the design view, so I no longer can
use the design features of Visual Studio, if I were to directly bind to
a dataset.

- There is no out of the box feature to persist a dataset between
postbacks. So, like in 1.1, if I were to go this route, I would have to
persist it in session.

I was wondering if there is anybody out there who used the 1.1 data
access in a similar fashion, and how you adapted to 2.0.

Thank you for your comments.

Evgueni

Hi Evgueni,

You can create a strongly typed DS without table adapters also. Simplest way is to just open the DS in the designer and delete the adapter part. You can then use this DS to bind to a gridView (like in 1.1) but you need to manually write code to add rows to it. Alternatively, you can use an ObjectDatasource and let it handle the DB code itself.

HTH,

Vivek

Wouldn't that be great, if there was a data source object that would out of the box:

- bind directly to a dataset, not table adapters
- know how to persist the dataset between postbacks (maybe different persistence models such as session or cache)
- have the load and update methods to interact with the database

Basically, Windows Forms pattern -- but in a stateless environment. This would greatly assist us with creating cancellable forms such as wizard and complex master/child forms.

Am I talking non-sense, or is it something that people could use in ASP.NET?

Data source controls controls can either directly connect to a data store such as a DB or XML files, or to a business object (such as a strongly typed dataset). They act like a "broker" dealing with the manipulation of data so that the developer is spared of writing too much standard data access code. So an object data source can bind directly to a dataset (and you need to create a strongly typed dataset for it, or a custom business object) and also support caching. When using typed datasets, the VS 2005 designer creates TableAdapters for the Datasets, which is an advanced and quite useful feature considering the fact that TableAdapters extend DataAdpaters.

Now when we talk about binding directly to a dataset, this we can easily do, but tableAdapeters help us to avoid writing CRUD code (with the help of VS designer) and save time. You can very easily attach Load and Update methods using TableAdapter to bind to a particular table in the DB. So my point is that TableAdapters are just some "nitro boosted" form of DataAdapters, and while using them you are infact binding with the typed Datasets only.

Summarising, all your requirements can be easily met with the new ADO.NET and VS 2005 designer features in .NET 2.0.

Let me know if you need more details.

Vivek

Vivek, thank you for your response.

I understand that what I am asking for can be done in .NET 2.0. My point is that you actually have to write code if you want to bind directly to a dataset, and I don't want to do that. For example, I want to bind directly to the dataset, and maintain a full design-time experience like I had in 2003. I can't do that now because the Data Source property is not available in the designer. Am I missing something here?

Evgueni

Evgueni,

You can use the DataSource property for the GridView in the code behind, but the reason it is not there in the Properties window is due to the fact that if we bind a gridview to a non-datasourcecontrol object, we need to provide custom paging. So it is advisable to use an ObjectDataSource which is connected to a strongly typed dataset with a gridview. All relevant designer properties would be supported.

Let me know if you still face issues with this approach.

Vivek