Den "riktige" måten å aksessere databaser fra webapplikasjoner på

[Scumtron]

Hei. Jeg holder på å lære meg å lage webapplikasjoner i .NET med ASP.NET/C# (kommer fra Javabakgrunn). I den forbindelse har jeg begynt å sette meg inn i aksessering av databaser fra mine websider. Det virker som om det finnes flere måter å gjøre dette på, så jeg lurer på hva som er den "riktige" / mest gunstige måter å gjøre dette på hvis jeg vil lage oversiktlige multi-tier-applikasjoner med god separasjon av presentasjon og logikk, uten for mye kodeduplisering.

 

I de første tutorial-ene jeg gikk gjennom ble det benyttet SqlDataSource-kontroller direkte på sidene, noe som ikke er særlig gunstig da SQL-kommandoer blir lagret i selve sidekoden. Så begynte jeg å utforske bruk av definerte datasett, med bruk av adaptere (XxxDataSetTableAdapters.YyyTableAdapter osv.), og GetData for å hente ut tabeller. Dette er noe bedre, men jeg må fortsatt opprette de samme adapterne i hver code-behind-fil.

 

Noen generelle retningslinjer / best practices her? Mulig dette er et veldig vagt spørsmål...

[serverside]

Tror kanskje du kan finne litt hjelp i artikkelen Data Access Layer (DAL) og enkelt oppsett av objekter mot database med C# (Objektorientert data-access)

[Manfred]

Helt personlig mener jeg at "Three-tier" slik det vises på endel websider og slike ting er en unødvendig komplisert måte å legge ting opp på.

 

Når det kommer til organisering av filer og "tiers" i .NET ville jeg anbefalt å samle kode som skal brukes flere ganger av samme filer i klasser i "App_Code". All annen kode lar du ligge i .aspx.cs-fila.

 

.NET har jo lagt opp til en two/three-tier på en måte ved at design og kode er helt skilt i hver sin fil. Når man da i tillegg introduserer App_Code for flerbrukskode, mener jeg man legger opp .NET-applikasjonen "riktig"

[serverside]

Helt personlig mener jeg at "Three-tier" slik det vises på endel websider og slike ting er en unødvendig komplisert måte å legge ting opp på.

 

Når det kommer til organisering av filer og "tiers" i .NET ville jeg anbefalt å samle kode som skal brukes flere ganger av samme filer i klasser i "App_Code". All annen kode lar du ligge i .aspx.cs-fila.

 

.NET har jo lagt opp til en two/three-tier på en måte ved at design og kode er helt skilt i hver sin fil. Når man da i tillegg introduserer App_Code for flerbrukskode, mener jeg man legger opp .NET-applikasjonen "riktig"

 

Er egentlig ganske uenig i det du skriver her. Uansett om det er en liten eller stor applikasjon bør man skille mellom dataaccess, logikk og presentasjon. Det er mange grunner til dette bla skalerbarhet og vedlikehold. App_Code-mappen er en mappe som er beregnet på websites (ikke webapplications). En website kompileres "on the fly" mens en webapplication kompileres til en dll i bin-mappen. Vedlikehold av en webapplication er derfor langt enklere.

 

Å putte masse logikk/kode i codebehind-filer vil før eller siden medføre at du har funksjoner spredt over alt som gjør de samme tingene. I et webprosjekt (uansett site/application) bør man skille ut alt annet enn presentasjon. En annen viktig ting er at det fort blir veldig uoversiktlig og rotete med masse kode/logikk i codebehindfilene.

[Manfred]

Det blir det også litt "smak og behag" mener jeg.

 

Jeg legger så og si alltid logikk og dataaccess til en spesifikk side i codebehind. Rett og slett fordi jeg synes det er mye mer oversiktilig.

 

Det er sjelden jeg kompilerer opp en webapplication. Derfor blir det også riktig å bruke App_Code, etter hva du sier.

 

Når det kommer til precompiled WebApplication eller uncompiled WebSite, så mener jeg at precompiled bruker man kun om man skal lage noe for en kunde eller lignende, hvor de ikke skal ha tilgang til koden. Eller dersom du er litt paraniod. Når det kommer til hastighetsforskjellen er den minimal.

[serverside]

Scumtron spør: "jeg lurer på hva som er den "riktige" / mest gunstige måter å gjøre dette på hvis jeg vil lage oversiktlige multi-tier-applikasjoner med god separasjon av presentasjon og logikk, uten for mye kodeduplisering."

 

Følg best practice, del applikasjonen din i flere deler med hver sin oppgave. Det å putte all koden sin i en svær kodedæsj codebehind er noe som henger igjen fra gamledager da man brukte script i stedet for programmering.

 

Et par andre tips:

- Ikke bruk en gridview hvis det holder med en repeater

- Et dataset inneholder som regel langt mer funksjonalitet enn du trenger. Bruk strongly typed collections med egendefinerte objekter.

- Den aller raskeste måten å lese data fra en database er med en DataReader. Å bruke dataadapter til å fylle et dataset med data er liten vits og vil bare bremse ytelsen din.

- Bruk stored procedures i databasen. Både mtp sikkerhet, ryddighet og ytelse

 

Det er dessverre veldig mange tutorials på nettet der det brukes nettopp dataset's og dataadapter osv. En ting som er greit å vite er at et dataset er en samling med datatables (kan til og med ha relasjoner). I de fleste tutorials bruker man et dataset til å presentere en tabell med data. Det faller på sin egen uvitenhet. Jeg personlig bruker aldri dataset, men kun strongly typed collections (s.t.p er en collection med objekter av en definert type)

 

Artikkelen Data Access Layer (DAL) og enkelt oppsett av objekter mot database dekker nettopp et enkelt eksempel av en komplett 3-lags webapplikasjon.

[Manfred]

Scumtron spør: "jeg lurer på hva som er den "riktige" / mest gunstige måter å gjøre dette på hvis jeg vil lage oversiktlige multi-tier-applikasjoner med god separasjon av presentasjon og logikk, uten for mye kodeduplisering."

 

Følg best practice, del applikasjonen din i flere deler med hver sin oppgave. Det å putte all koden sin i en svær kodedæsj codebehind er noe som henger igjen fra gamledager da man brukte script i stedet for programmering.

Her tror jeg du må se litt på HVA som skal utvikles også. Det er ikke alltid EN løsning er best uansett hva slags system vi snakker om.

[serverside]

Scumtron spør: "jeg lurer på hva som er den "riktige" / mest gunstige måter å gjøre dette på hvis jeg vil lage oversiktlige multi-tier-applikasjoner med god separasjon av presentasjon og logikk, uten for mye kodeduplisering."

 

Følg best practice, del applikasjonen din i flere deler med hver sin oppgave. Det å putte all koden sin i en svær kodedæsj codebehind er noe som henger igjen fra gamledager da man brukte script i stedet for programmering.

Her tror jeg du må se litt på HVA som skal utvikles også. Det er ikke alltid EN løsning er best uansett hva slags system vi snakker om.

 

Klart det . Ingen vits å overeskalere et løp. Men man bør følge noen enkle rammer og retningslinjer. Men poenget er at hvis man gjør seg kjent med det og bruker det så vil man spare masse tid. Man vet hvor man skal putte hva og slipper å flytte på ting og rekonstruere koden sin. Og ikke minst den dagen man skal endre applikasjonen. Da er det greit å vite hvor man finner hva og hvordan ting henger sammen grovt sett. Ved å følge noen rammer (som er velkjent og utprøvd) så vil man bruke mindre tid på debugging også. Nettopp fordi man jobber i kjente rammer.

[Wubbable]

(Objektorientert data-access)

Sier kun en ting: DB4O (Database for objects)

[Manfred]

Enkle rammer og retningslinjer er jo forsåvidt et must om man vil jobbe videre på prosjektet senere.

 

Men å dele all programlogikk og dataaksess i hvert sitt lag blir stort sett "overkill" med mindre man jobber med digre prosjekter med mange utviklere og slikt.

 

Jeg jobber på relativt store prosjekter hvor jeg har gjennomført det som beskrevet over, som har vært veldig enkle og greie å jobbe med og utvide kraftig..