Databashantering

Kan ju bara meddela att allt fungerar bra!

Måste dock komma på något bra sätt att hantera felhanteringen....

Toppen! :bire Kul att det fungerar.

Felhanteringen skall bli intressant att höra hur du löser. Har du nån plan för det än?

Nja vet inte om det behövs ;) Har inte haft några fel än så länge.... men du har kasnke några tips :q

Har läst denna tråd med stort intresse och med de lilla kunskaper jag har om ämnet så hoppar jag rakt in i debatten.

Har lästs om hOlgers 4-6 skickade lösningar, där man lagrar SQL-satser och parameters i XML-filer. Och håller med om att man får ett otroligt flexibelt system, även det att man alltid skickar tillbaka en XML-fil och aldrig något objekt, asbra för svarta låder som man säljer.

Tyvärr finns det alltid en nackdel med detta och det är prestandan. Ju fler skikt man har ju fler hopp och desto fler referenser måste göras. Så du har 2 vägar att välja, bygg ett system som är där du kan byta ut skikt utan att något annat påverkas. Eller så satsar man på prestanda och skaffar sig 3 skikt.

1. ASPX-sidan, som visar din utdata
2. Din codebehind sida där du kör direkt mot System.Data.SqlClient och inte skapar din egen DataBasklass.
3. Din databas fungerar som ditt datalager.

Nu har du låst in dig rätt så bra och om något ändras så har du mycket att ändra på, men du har ett system som är snabbare. Nu säger säkert någon att det är bra med många skikt eftersom man då får ett skalbart system som kan delas upp på fler maskiner än vad mitt kan, och det stämmer, men tro inte att den uppdelningen är gratis, det kostar overhead i nätverkstrafiken och blir det riktigt mycket trafik så får man kollisoner och en massa omsändningar som genrerar mer trafik osv osv...

Läste även om felhanteringen att man inte skall göra den själv utan använda exceptions och jag tycker inte man skall göra det om man kan kontrollera själv (till ASP.NET, inte DLL som jag tänker återanvända) och det har också med prestandan att göra, kan man stänga av felhanteringen helt så har man vunnit mycket prestanda, men då vill det till att man kodat bra också.

Så återigen, ställ prestanda mot flexibilitet.

- Magnus

Mina 5 ören

Intressant synvinkel. Håller du med om det Gladh skriver, Holger?

Intressanta kommentarer...

Hur står kan då skillnaden i prestandard vara om man jämför ditt 3-skiktsystem mot ett 4-5 skikt utan att använda sig av sql satser sparade i xml(vilket nog inte många gör)?

kan man stänga av felhanteringen helt så har man vunnit mycket prestanda, men då vill det till att man kodat bra också.

Ojoj, felhantering skall ALLTID finnas . I en skarp produkt är felhantering och ordentlig loggning minst lika viktigt som prestandan, det ena får inte diskvalificera det andra. Oavsett hur "bra" man kodat så sker fel, det är oundvikligt. Skiter man i att ordna bra felhantering så är man ute på hal is.

Nu menar jag inte att man inte skall ha felhantering, bara att man skall stänga ev exceptions och själv gör felhanteringen, på detta sätt har man vunnit mycket i prestanda.

Men som sagt, det är inget man gör om man bygger en liten del av ett storsystem, utan kan användas till websiter som du kodar själv. Om man är satt att bygga en dll i ett stort system så skall man ha med exceptions där och kasta iväg det vid ett fel, upp i herakin eftersom jag då inte själv tar hand om felet.

Men återigen, vägg prestanda mot flexibillitet. Alla flaskhalsar kan inte köpas bort med bättre hårdvara även om mycket kan.

- M

Nu menar jag inte att man inte skall ha felhantering, bara att man skall stänga ev exceptions och själv gör felhanteringen, på detta sätt har man vunnit mycket i prestanda.

En liten fråga bara: Vad betyder att "stänga av exceptions"?

Nu menar jag inte att man inte skall ha felhantering, bara att man skall stänga ev exceptions och själv gör felhanteringen, på detta sätt har man vunnit mycket i prestanda.

Nu är jag ingen egentlig .NET-kodare, men jag är hyffsat säker på att .NET:s exception-stöd fungerar på samma sätt som i Java och då måste jag säga att jag inte förstår vad du menar.

Att fånga och hantera exceptions är ju A och O när det gäller felhantering, hur menar du att du skall implementera det själv? Jag antar att .NET-API:et slänger exceptions när något gått fel, vad gör du med dessa och framförallt, hur menar du att du kan ta hand om hand om det själv?

Om låt säga någonting i databaskommunikationen går snett, t.ex att det inte går att skapa en uppkoppling mot databasen då databasservern är nere, då antar jag att de API-klasser som man använder sig av för att kommunicera med databasen slänger ett eller flera exceptions?

Nu hittar jag inte var jag läste om det, dock är det så att om du får ett fel från din databaskommunikation så kan du inte göra mer.

Alltså behöver du inte ha en exception för att ta hand om det felet och skriva ut det, du kan istället låta ASP.NET's egna felhantering avbryta sidan och skicka dig till en felsida, eftersom funktionen ändå har förlorat sin funktion.

Jag hittade dock istället för något som bekräftar det jag säger, något som dementerar det och det är i Professional ASP.NET 1.0 från Wrox, där de säger att det INTE är någon prestanda förlust, vilket är precis tvärtemot det jag läst innan, måste se om jag kan hitta det igen.

Så fram till jag hittar var jag läste om att Exceptions tar kraft, så tar jag tillbaka mina tidigare påstående.

Men japp .NET's exceptions fungerar så som JAVA's

- M

Alltså behöver du inte ha en exception för att ta hand om det felet och skriva ut det, du kan istället låta ASP.NET's egna felhantering avbryta sidan och skicka dig till en felsida, eftersom funktionen ändå har förlorat sin funktion.

ASP.NET:s egna felhantering består ju egentligen av att hela Web-Formen är omsluten av ett "osynligt" try-catch-block. Om man själv hanterar felet i ett eget catch-block inne i sidan eller låter felet hoppa upp till det omgivande "osynliga" catch-blocket kan ju knappast spela så stor roll ur prestandasynpunkt.

Men jag förstår egentligen inte diskussionen. Execeptions är något som genomsyrar hela .NET. Man kan inte välja att slå på eller av det. Det enda man kan välja är var, om och hur man hanterar felen. Detta har, såvitt jag kan se, ingen naturlig eller omedelbar koppling till ordet "prestanda".

Nu hittar jag inte var jag läste om det, dock är det så att om du får ett fel från din databaskommunikation så kan du inte göra mer.

Visst, sker ett så pass allvarligt fel som att databasen är nere så är det inte mycket att berätta för användaren eftersom denne ändå inte kan göra något åt det hela, då räcker det att man visar en generell felsida av typen "fel, försök senare" typ.

Någon man däremot ALLTID skall göra i ett sådant läge är ju att fånga undantaget (exception) och LOGGA felet så att den som verkligen kan göra något åt det (administratören etc.) vet vad som har skett.

Bygger man ett system som bara hänsynslöst skiter i alla typer av exceptions utan att logga dessa så kommer man få problem efter driftsättning, felsökning kommer bli omöjligt...
Ungefär så här: ;)
"- Varför är inte system XYZ i drift?"
"- Vi vet inte, något mysko händer och den vägrar utföra begärd operation"
"- Fixa det då!"
"- Det går inte, vi har ingen aning om vad felet är eller beror på"

sgtpepper skrev:

Ungefär så här: ;)
"- Varför är inte system XYZ i drift?"
"- Vi vet inte, något mysko händer och den vägrar utföra begärd operation"
"- Fixa det då!"
"- Det går inte, vi har ingen aning om vad felet är eller beror på"

Är det inte så det skall gå till? ;)

Nackdelen med Gladhs model-view-controler lösning är att man kan få liknande affärsregler på mer än en plats. Ta t.ex. validering av användaruppgifter. När jag som användare sparar mina uppgifter efter jag t.ex. har bytt adress. Då anropas en aspx-sida som ligger tillgänglig för mig.

Samma validering måste göras då en administratör går in och uppdaterar kunduppgifter. Då anropas en annan aspx-sida som administratören har tillgång till.

Man har samma validering fast den ligger i olika aspx-sidor. Det lägger grunden för fel.

Om man dock vet med sig att man bygger ett litet, väl avgränsat system så kan man ta till sig denna arkitektur. Det är denna arkitektur som Microsoft använde sig av i Pet Store benchmarken och som är utvecklad enbart för prestanda inte för flexibilitet.

Felhantering skall alltid finnas. Det är inget man stänger av. Även om du inte hanterar dina exceptions så finns de där och de inträffar. Om inte du hanterar dina exceptions och gör nåt vettigt med dem så ger du dig själv problem som sgtpepper så träffande beskriver.

Kan ju bara säga att jag har uppgraderat "mitt" system så nu funkar det med mysql också. Verkligen bra!

Tänkte jag skulle dela med mig av hur jag har gjort, något sorts mellanting mellan Gladhs och h0lgers förslag. ;)
Jag tar en gästbok som exempel.

1. Aspx-presentationsskikt - här presenteras alla inlägg, html etc med form av repeaters, datalists och egensnickrade kontroller om så behövs.

2. Code-behind skikt - denna hämtar datan, alla inläggen, från affärslagret och binder dem till serverkontrollerna. Här görs kontroller på vad, var och hur datan ska skrivas ut på sidan (vanligtvis med If-satser).

3. Affärslagret - här är alla "globala" funktioner representerade, egentligen är detta uppdelat i "lager" också:

   A) Lagret som kommunicerar med code-behind och retunerar data i form av ett DataSet. Allt som retuneras till code-behinden är i stort sett DataSet, ArrayList eller strängar. Detta lagret kommunicerar i sin tur med:

   B) Det riktiga affärslagret där den "tråkiga" logiken sitter. Här ligger bl a en databasklass som hämtar & kör data genom databasen. Fördelen med detta är att det är enkelt att byta providers från exempelvis Sql till OleDb utan att något annat påverkas.

4. Datalagret - databasen.

Fördelen med detta, som jag ser det, är att det inte är så extremt "lager-inriktat" utan mer funktionsinriktat. Att byta databasprovider är inga problem eftersom det sköts i en egen klass. I princip alla SQL-satser ligger i affärslagret (3A) och retuneras som "vanliga" datatyper (DataSet, ArrayList m.m.) för att man inte ska behöva använda OleDbDataReader eller SqlDataReader.

Att lagra SQL-satser i XML-filer är totalt overkill för min del eftersom SQL-satserna skapas dynamiskt baserad på mycket annat, vilket skulle bli en plågsam lösning att sitta och pilla med XML. Då skulle jag hellre investera i MSSQL och köra stored procedures.

Min lösning är alltså lite gnutta av varje och slå ihop det i en röra som passar en själv (jag kan kategoriseras som hobbyprogrammerare), men samtidigt är kraftfullt och skalbart nog att överföras och ändras ganska friskt.

Verkar som en vettig lösning. Det viktiga är att man hittar rätt ambitionsnivå för sitt system.

Tack för att du delade med dig av din lösning.

Ligger valideringar etc i 3a lagret eller i 3b?

Skulle vara intressant att veta hur du hanterar felhantering?

Ligger valideringar etc i 3a lagret eller i 3b?

Det beror på vad du menar med valideringar. I aspx-sidorna ligger formulärvalidering. Behövs det mer formulärvalidering så ligger de i code-behind-filerna där även QueryString valideringar etc görs. Affärslagret har i skrivande stund inga som helst valideringar, utan det är tänkt att all data som skickas in dit är giltlig. SQL-valideringar (t ex att göra om ' till '') sköts dock av lager 3A som använder sig av de funktioner som ligger i 3B.

Min tanke är att code-behind-filerna skyfflar data mellan aspx och affärslagret, och ser samtidigt till att den är korrekt.

Skulle vara intressant att veta hur du hanterar felhantering?

All felhantering hanteras i 3B, främst när man kopplar upp sig till databasen, och slänger iväg ett eget exception med lite information från vilken klass den kom ifrån (t ex "Fel uppstod i Metodensnamn(): Felmeddelande här").

Annars behövs ingen felhantering, för det blir inga fel förutom på detta ställe.