Strongly typed datasets ASP.NET

[ThatsIT.net.au]

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?

 

[Alberto Poblacion]

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.

 

[ThatsIT.net.au]

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

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?

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

 

[Mr. Arnold]

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/.../12/new-assemblies-net-framework-3-5-sp1.aspx>

<http://geekswithblogs.net/frankw/ar...ework-and-data-services-in-action-part-1.aspx>

<http://www.microsoft.com/downloads/...04-8E05-41FC-94C8-C73D9E238F82&displaylang=en>

You should think the Model and design patterns.

http://en.wikipedia.org/wiki/Domain-driven_design

 

[Pavel Minaev]

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.

 

[Mr. Arnold]

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.