Datasets in framework 2.0

  • Thread starter Thread starter eugenet
  • Start date Start date
E

eugenet

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 data 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
 
Evgueni,

It seems that your problem is in overestimating the role of the designer. In
fact, many developers, including myself, hardly use the designer at all. You
can achieve everything in the html view and in the code much more
efficiently, without relying on sometimes obscure logic of the designer.
Then you will find you can continue handling datasets in exactly the same
way as in 1.1.
 
Eliyahu, thank you for your reply.

I hear you about doing things manually, but one of the main reasons I
switched to .NET was to be more productive. I recognized the fact that
Microsoft was pushing data binding and rich design time experience and
accepted it as a part of my coding style. So, in 1.1 it worked very
well -- generate a strongly-typed dataset, bind it to controls, but
then manually control how/when data gets pushed/pulled from the
dataset. It was both productive and efficient.

It seems that in 2.0, Microsoft provides a rich design experience to
those folks who can leave with multiple round trips to the database,
but to those who want to take advantage of design features, while have
control over data access, things got a little more complicated.

Perhaps, extending DataSource control is the way to go in order to
accomplish what I need. I will look into that next.

Evgueni




Eliyahu said:
Evgueni,

It seems that your problem is in overestimating the role of the designer. In
fact, many developers, including myself, hardly use the designer at all. You
can achieve everything in the html view and in the code much more
efficiently, without relying on sometimes obscure logic of the designer.
Then you will find you can continue handling datasets in exactly the same
way as in 1.1.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]


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 data 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
Click to expand...
Click to expand...
 
Back
Top