Datasets in framework 2.0

Discussion in 'ASP .Net' started by eugenet@rusmex.com, Sep 11, 2006.

  1. Guest

    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
     
    , Sep 11, 2006
    #1
    1. Advertising

  2. 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]


    <> wrote in message
    news:...
    > 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
    >
     
    Eliyahu Goldin, Sep 12, 2006
    #2
    1. Advertising

  3. Guest

    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 Goldin wrote:
    > 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]
    >
    >
    > <> wrote in message
    > news:...
    > > 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
    > >
     
    , Sep 12, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. news.microsoft.com
    Replies:
    0
    Views:
    460
    news.microsoft.com
    Apr 12, 2006
  2. Francisco Garcia
    Replies:
    2
    Views:
    499
    Fran Garcia
    Apr 13, 2006
  3. Matt
    Replies:
    3
    Views:
    224
    Dan Rogers
    Nov 29, 2004
  4. news.microsoft.com
    Replies:
    0
    Views:
    212
    news.microsoft.com
    Apr 12, 2006
  5. Francisco Garcia
    Replies:
    3
    Views:
    275
    vincent
    Apr 13, 2006
Loading...

Share This Page