Hej

Har surfat runt en del och försökt skapa mig en uppfattning om hur man bygger optimalt i .Net.

Över allt och i princip alla exempel över allt så arbetar man med DataSet som man skapar ett antal tabeller i och så skapar man relationer i dessa. Man använder sällan where satser för att begränsa mängden data utan man hämtar hela tabeller.

Nästan alltid så använder man select satser i koden istället för att anropa Stored Procedures i databasen.

Jag har alltid blivit i tutad att man skall ej ha sql kod i programmet och att man skall begränsa mängden data.I och försig så försvinner ju behovet av att blacera SQL satsen utanför koden om man har ett välskrivet datalager...

Vilket är rätt?! Vad är grundfilosofin med .Net?!

Skall jag skapa ett DataSet inan, en "mall"?
Skall jag fylla DataSet vi Select sats eller Stored Procedure?
Skall jag skapa flera tabeller i mitt DataSet och fixa relationerna i DataSet eller skall jag göra detta via en Stored Procedure och läsa in all data i en tabelli DataSet?

Roger

Det beror på var ditt program ska göra. Av prestanda skäl, hämta så lite data som möjligt från databasen, avnänd SP för att få upp prestandan (OBS! behöver inte bli bättre prestanda för att du använder SP, beror på frågan).

Jag själv använder inte DataSet utan Entitets objekt. Dessa fylls upp med hjälp av en broker som jag har implementerat, påminner mycket om objectspace.

Ett tips ta ner Petshop 3.0 från GotDotNet.

Här är en lista av förslat när ett DataSet kan vara bra och en DataReader

När kan det vara bra att använda ett Dataset?

•När du ska transportera data mellan skikten i en distribuerad applikation Ett dataset är beroende av någon datalkälla och all datainformation är lagrad i minnet. Detta gör det både enkelt och möjligt att transportera data med hjälp av ett dataset mellan skikten i en distribuerad applikation.

•När data ska utbytas med andra applikationer Ett dataset kan serialisera data till XML och läsa och skriva XML-scheman och är därför ett utmärkt alternativ vid utbyte av data med andra applikationer.

•När du vill arbeta med flera tabeller Ett dataset innehåller en eller flera tabeller som kan representera data från olika datakällor. När datan väl finns i dataset, så är det lätt att hantera datan och relatera datan till ett homogent format så det ser ut som datan kommer från en datakälla. Du kan arbeta med en tabell individuellt eller navigera mellan förälder- och barn-tabeller. Du kan också tvinga på dataintegritet i ett dataset gemom att använda UniqueConstraint och ForeignKeyConstraint objekten.

•När du vill hantera data på ett enkelt sätt Ett dataset har ett flertal metoder för att göra utsökning av data, filtrera och sortera data utan prestandakrävnade åtkomst till databas. För att göra det mer enkelt att använda ett dataset så kan du generera en klass som representerar strukturen av datasetet (t ex en user-tabell i ett dataset kan lätt bli åtkomligt som dataset.User). Detta kallas för ett typat dataset. Ett typat dataset gör det lättare, ger en renare kod, och reducerar risken att skapa fel när man utvecklar applikationer med hjälp av ett typat dataset eftersom Visual Studio.Net stödjer verktyg som t ex IntelliSense osv.

•När du vill använda XSLT för att formatera data till olika format Dataset i grunden är uppbygd med XML och gör det extra enkelt att använda XSLT för att formatera om datan till olika format som tex HTML, PDF etc.

•När du vill enkelt binda data till server kontroller För enkelhets skull så kan du binda ett dataset till kontroller (En kontroll kan tex vara en text ruta) i ett Web Form eller Windows Form och genom detta undvika att själv manuellt behöva lägga till data till en kontroll. Med kontroller som datagrid kan du skapa möjligheter till att navigera genom datan i ett dataset.

Ett dataset fylls upp av en datareader och byggs upp av flera objekt. Nackdelen med detta är att ett dataset kan bli onödigt stort. Så för att enbart presentera data så är
ofta datareadern ett bättre alternativ, speciellt för att få upp prestandan.

Fördelar med en DataReader:

•Effektivare vid presentation av data DataReadern behöver inte som ett Dataset skapa onödiga objekt eller göra onödig datakopiering. Vid felertal metod anrop mot en DataReader t.ex. när data ska hämtas med t.ex. GetValue flera gånger, så returneras en refererens till samma objekt. DataReadern fylls inte med data vilket leder till en bättre prestanda jämfört vid användning av ett Dataset som fylls med data. I de situationer en tillämpning ska presentera data utifrån en datakälla, så är det mycket effektivare att läsa direkt från databasen.

•Uthämtning av både resultat och utprametrar Vid exekitering av Stored procedures så kan både ett resultatset och utparametrar hämtas. DataAdaptern har inte denna möjlighet.

Nackdelar med en DataReader:

•Egen uppkoppling DataReadern är i behov av en egen uppkoppling. När en DataReader använder sig av en uppkoppling så kan inte andra operationer göras mot samma uppkoppling. Något annat som är bra att tänka på är att data utifrån ett SQL-uttrycks utparametrar inte är tillgängliga under den tid som en DataReader är i användning. För att kunna använda samma uppkoppling som en Datareader vid hämtning av utparameterar eller utförandet av andra operationer, så måste en DataReader stängas eller en ny uppkoppling skapas vilket kan leda till dålig skalbarhet och prestanda. För att släppa en DataReaderns uppkoppling så anvönds metoden Close för en DataReader.

•Sortinger av data sker på databas nivå Eftersom en DataReader läser av rad för rad utifrån ett resultatetsett från databasen, så finns det inga möjligheter till sortering med hjälp av själva DataReadern. Sorteringen av data kan göras med hjälp tex Order by i ett SQL-uttryck. Problemet med Order by är att soreteringen av data följer den språkinställning som databasen använder sig av. Detta är ett stort problem i tillämpningar som är placerad centralt och riktad globalt mot olika kulturer. Ett Dataset har den fördelen att den kan själv sortera data utefter en angiven kultur.

Försök att använda Command objektet för att hämta data, använd DataReaders vid visning av data. Detta för att Web Forms-sidor och dess kontroller och komponenter återskapas vid varje omladdning av sidan, det är ofta inte så effektivt att fylla ett datasets varje gång, om inte datasetet lagras mellan sidornas omladdningar.

Använd Command objektet (och om passande, använd DataReader) under följande förhållanden:

•När du inte behöver behålla datan mellan omladdningarna av en sida.
•När du ska hämta ut ett värde från ett SQL-uttryck med ExecuteScalar. ExecuteScalar returnerar värdet från första kolumnen och raden i ett resultat.
•När du behöver utför Stored Procedures för att utföra logik i databasen.
•Om du utför SQL-uttryck som inte ska returnera data. Tex Insert, delete och update.

/Fredrik Normén NSQUARED2
http://www.nsquared2.net

Eller läs följande artiklar:

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnbda/html/BOAGag.asp

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnbda/html/bdadotnetarch031.asp

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnbda/html/daag.asp

och till slut du kan ju alltid använda dig av våra applicationblocks, se:
http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnbda/html/daab-rm.asp

Lycka till!