Strongly typed datasets ASP.NET

Discussion in 'ASP .Net' started by ThatsIT.net.au, Mar 28, 2009.

  1. I have never user strongly typed datasets much but in a current ASP.NET
    project I decided to give them a try.

    What I wanted to know is what is best practice on a few things.
    The current project has only 4 tables in the database, 1 is just holding a
    few settings the other 3 are holding the clients data. they are category
    subcategory and product.

    Should I have all 3 database tables represented on the same .xsd or should I
    separate?
    I read that they are fully cached, what is meant by that, what scope and
    where is it cached and for who?
    Are they really best for ASP.NET or are they suited better windows forms?
    pros? cons? ideas?
     
    ThatsIT.net.au, Mar 28, 2009
    #1
    1. Advertising

  2. "ThatsIT.net.au" <me@work> wrote in message
    news:...
    > What I wanted to know is what is best practice on a few things.
    > The current project has only 4 tables in the database, 1 is just holding a
    > few settings the other 3 are holding the clients data. they are category
    > subcategory and product.
    >
    > Should I have all 3 database tables represented on the same .xsd or should
    > I separate?


    That depends on what you want to do. If you want to use GetChildRows or
    GetParentRow to navigate the relationships between the tables that you have
    loaded in memory, then you want all the tables in the same dataset.
    Otherwise it doesn't matter much. You can use a dataset for each table, or
    define several tables in one dataset but only load the data you need, and
    leave the others empty the rest of the time.

    > I read that they are fully cached, what is meant by that, what scope and
    > where is it cached and for who?


    The dataset itself is not automatically cached. If you declare an
    instance of a dataset as a local variable in a method, load it with data,
    use the data, and then exit the method, the dataset will become available to
    garbage collection and not be cached at all. Similarly, if it is a member of
    your System.Web.UI.Page class, it will be discarded after each postback of
    the page. If you want to cache the DataSet, you can keep it in the Session
    state if you want to keep a copy per session, or in the Application state if
    you want it to be permanently available to all users, or preferably in the
    Cache, where asp.net can automatically discard it if it needs the memory for
    other purposes. You can even keep it in the ViewState if it is specific to a
    single page and it doesn't contain a lot of information. All of this has to
    be programmed by yourself, it doesn't happen automatically.

    > Are they really best for ASP.NET or are they suited better windows forms?
    > pros? cons? ideas?


    It doesn't really make a difference. You can use DataSets, typed or not,
    either on WinForms or on WebForms, and also on Services or Console
    applications. In every case you need to be aware of which information you
    are loading into the DataSet and when, and what is the lifetime of the
    dataset according to how you are using it. It's all in your code.
     
    Alberto Poblacion, Mar 28, 2009
    #2
    1. Advertising

  3. "Alberto Poblacion" <> wrote
    in message news:...
    > "ThatsIT.net.au" <me@work> wrote in message
    > news:...
    >> What I wanted to know is what is best practice on a few things.
    >> The current project has only 4 tables in the database, 1 is just holding
    >> a few settings the other 3 are holding the clients data. they are
    >> category subcategory and product.
    >>
    >> Should I have all 3 database tables represented on the same .xsd or
    >> should I separate?

    >
    > That depends on what you want to do. If you want to use GetChildRows or
    > GetParentRow to navigate the relationships between the tables that you
    > have loaded in memory, then you want all the tables in the same dataset.
    > Otherwise it doesn't matter much. You can use a dataset for each table, or
    > define several tables in one dataset but only load the data you need, and
    > leave the others empty the rest of the time.


    Thanks as I expected

    >
    >> I read that they are fully cached, what is meant by that, what scope and
    >> where is it cached and for who?

    >
    > The dataset itself is not automatically cached. If you declare an
    > instance of a dataset as a local variable in a method, load it with data,
    > use the data, and then exit the method, the dataset will become available
    > to garbage collection and not be cached at all. Similarly, if it is a
    > member of your System.Web.UI.Page class, it will be discarded after each
    > postback of the page. If you want to cache the DataSet, you can keep it in
    > the Session state if you want to keep a copy per session, or in the
    > Application state if you want it to be permanently available to all users,
    > or preferably in the Cache, where asp.net can automatically discard it if
    > it needs the memory for other purposes. You can even keep it in the
    > ViewState if it is specific to a single page and it doesn't contain a lot
    > of information. All of this has to be programmed by yourself, it doesn't
    > happen automatically.
    >


    so its just just any dataset?
    I read at MSDN that they were fully cached, I wondered what FULLY meant?



    >> Are they really best for ASP.NET or are they suited better windows forms?
    >> pros? cons? ideas?

    >
    > It doesn't really make a difference. You can use DataSets, typed or not,
    > either on WinForms or on WebForms, and also on Services or Console
    > applications. In every case you need to be aware of which information you
    > are loading into the DataSet and when, and what is the lifetime of the
    > dataset according to how you are using it. It's all in your code.
    >


    That question was from my confusion with FULLY cached.

    I do Have one more question
    Lets say you have 3 functions on a table adapter all need to pull different
    data before filling a data table, is this preferable to creating 3 separate
    table Adapters
     
    ThatsIT.net.au, Mar 28, 2009
    #3
  4. ThatsIT.net.au

    Mr. Arnold Guest

    "ThatsIT.net.au" <me@work> wrote in message
    news:...
    >I have never user strongly typed datasets much but in a current ASP.NET
    >project I decided to give them a try.
    >
    > What I wanted to know is what is best practice on a few things.
    > The current project has only 4 tables in the database, 1 is just holding a
    > few settings the other 3 are holding the clients data. they are category
    > subcategory and product.
    >
    > Should I have all 3 database tables represented on the same .xsd or should
    > I separate?
    > I read that they are fully cached, what is meant by that, what scope and
    > where is it cached and for who?
    > Are they really best for ASP.NET or are they suited better windows forms?
    > pros? cons? ideas?


    If you're using VS 2008 with your ASP.NET solution, then you should dump
    Datasets altogether and use the ADO.NET Entity Framework.

    <http://en.wikipedia.org/wiki/O-RM>

    <http://en.wikipedia.org/wiki/Language_Integrated_Query>

    <http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework>

    <http://www.vbforums.com/showthread.php?t=540421>

    <http://marlongrech.wordpress.com/category/linq/>

    <http://blogs.msdn.com/astoriateam/>

    <http://blogs.microsoft.co.il/blogs/bursteg/archive/2008/05/12/new-assemblies-net-framework-3-5-sp1.aspx>

    <http://geekswithblogs.net/frankw/archive/2008/03/08/ado.net-entity-framework-and-data-services-in-action-part-1.aspx>

    <http://www.microsoft.com/downloads/details.aspx?FamilyId=D8AE4404-8E05-41FC-94C8-C73D9E238F82&displaylang=en>

    You should think the Model and design patterns.

    http://en.wikipedia.org/wiki/Domain-driven_design
     
    Mr. Arnold, Mar 28, 2009
    #4
  5. ThatsIT.net.au

    Pavel Minaev Guest

    On Mar 28, 10:52 am, "Mr. Arnold" <MR. > wrote:
    > "ThatsIT.net.au" <me@work> wrote in message
    >
    > news:...
    >
    > >I have never user strongly typed datasets much but in a current ASP.NET
    > >project I decided to give them a try.

    >
    > > What I wanted to know is what is best practice on a few things.
    > > The current project has only 4 tables in the database, 1 is just holding a
    > > few settings the other 3 are holding the clients data. they are category
    > > subcategory and product.

    >
    > > Should I have all 3 database tables represented on the same .xsd or should
    > > I separate?
    > > I read that they are fully cached, what is meant by that, what scope and
    > > where is it cached and for who?
    > > Are they really best for ASP.NET or are they suited better windows forms?
    > > pros? cons? ideas?

    >
    > If you're using VS 2008 with your ASP.NET solution, then you should dump
    > Datasets altogether and use the ADO.NET Entity Framework.


    That's a rather categorical statement. EF is fairly heavyweight, and
    its complexity may be overkill for simpler tasks. For 4 tables and a
    simple GUI, typed datasets may be both faster and easier to work with.
     
    Pavel Minaev, Mar 28, 2009
    #5
  6. ThatsIT.net.au

    Mr. Arnold Guest

    "Pavel Minaev" <> wrote in message
    news:...
    On Mar 28, 10:52 am, "Mr. Arnold" <MR. > wrote:
    > "ThatsIT.net.au" <me@work> wrote in message
    >
    > news:...
    >
    > >I have never user strongly typed datasets much but in a current ASP.NET
    > >project I decided to give them a try.

    >
    > > What I wanted to know is what is best practice on a few things.
    > > The current project has only 4 tables in the database, 1 is just holding
    > > a
    > > few settings the other 3 are holding the clients data. they are category
    > > subcategory and product.

    >
    > > Should I have all 3 database tables represented on the same .xsd or
    > > should
    > > I separate?
    > > I read that they are fully cached, what is meant by that, what scope and
    > > where is it cached and for who?
    > > Are they really best for ASP.NET or are they suited better windows
    > > forms?
    > > pros? cons? ideas?

    >
    > If you're using VS 2008 with your ASP.NET solution, then you should dump
    > Datasets altogether and use the ADO.NET Entity Framework.


    That's a rather categorical statement. EF is fairly heavyweight, and
    its complexity may be overkill for simpler tasks. For 4 tables and a
    simple GUI, typed datasets may be both faster and easier to work with.

    -----------------------------------------------------------

    I disagree, particularly, so when I found out how to create a ASP.NET Web
    Dataservice with the EF Model on the backend using REST, in Read-Only mode.
    I use it in a simple task of doing Linq Queries against the Model of two
    tables for searching, like a Linq Service Provider. It's lightning fast,
    and I have been told that more EF Models for data searching will be
    implemented.

    I also am working on ASP.NET social community, search engine, jack of all
    trades master of none, etc, etc that's based on datasets as kind of a DTO
    solution with the DAL and Web services within the solution.

    I have already been told by those that have worked in that environment on
    the solution for a number of years, that they can see the speed difference
    in the new technology such EF as opposed to the old dataset technology,
    dealing with the SQL server database and persistence that's being
    implemented in a new project I am working on.

    If you look at the examples of using an ASP.NET Dataservice with EF and REST
    that I have provided, it can do it all, such as adds, updates, reads and
    deletes with a minimal amount of time and programming effort, and the speed
    man the speed of it, as long as one doesn't immediate loading on Linq
    queries. . Some may want to take the Dataservice past the read-only mode
    that all only use it for, and use a more traditional usage BLL/DAL/Model for
    simple CRUD.

    ASP.NET Web Dataservice, REST and EF makes EF light.

    The ADO.NET Entity Framework is fabulous technology, and as long as I have
    anything to do with an ASP.NET Web solution development that deals with the
    database, a dataset will not see that light of day again if I can help it.

    Also, I have not written a sproc using EF either. It's fabulous.
     
    Mr. Arnold, Mar 28, 2009
    #6
    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. Big D

    Strongly typed datasets and XML

    Big D, Feb 17, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    462
    bruce barker
    Feb 17, 2004
  2. Duncan Welch

    Strongly typed datasets and nested repeaters

    Duncan Welch, Apr 7, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    2,034
    MattC
    Apr 7, 2005
  3. chris
    Replies:
    2
    Views:
    2,062
    chris
    Feb 25, 2006
  4. Mike P

    strongly typed datasets

    Mike P, Aug 30, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    361
    Mike P
    Aug 30, 2006
  5. =?Utf-8?B?Vmlnag==?=

    strongly typed datasets-rdbms change

    =?Utf-8?B?Vmlnag==?=, Nov 20, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    288
    =?Utf-8?B?Vmlnag==?=
    Nov 20, 2006
Loading...

Share This Page