Strongly typed datasets ASP.NET

  • Thread starter Thread starter ThatsIT.net.au
  • Start date Start date
T

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?
 
ThatsIT.net.au said:
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?
Click to expand...

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
 
If you're using VS 2008 with your ASP.NET solution, then you should dump
Datasets altogether and use the ADO.NET Entity Framework.
Click to expand...

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.
 
If you're using VS 2008 with your ASP.NET solution, then you should dump
Datasets altogether and use the ADO.NET Entity Framework.
Click to expand...

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.
 
Back
Top