DB tilgang design, lagdeling?

der er adskillige artikler på MSDN med klassisk lag deling:
  presentation layer
  busines slogic layer
  data access layer

jeg kan godt prøve at se om jeg kan finde nogle links

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ArcThreeLayeredSvcsApp.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/EspPatternsForBuildingEnterpriseSolutions.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/AppArchCh1.asp

Hej Arne,

Tak for dine svar, artiklerne fortæller at der kan lagdeles, men der er ikke nogle tekniske spec på hvordan det overhovedet kan lade sig gøre.

Jeg har brug for mere præcise svar. Jeg kan sige at jeg selv har forsøgt at lagdele, ved at holde alt DB adgang i en klasse, og sql opdelt i forskellige klasser. Dermed har jeg et lag der kan returnere en datareader, DS mm. Det har dog den ulempe at jeg skal returnere en connection, hvis jeg bruger en datareader, da jeg skal lukke min connection efter mig.

Det er ikke nogen pæn lag deling. Jeg kunne selvfølgelig også lave nogle modelklasser, og returnere et array af dem fra mit datalag, det ville løse det problem, men her laver jeg en tæt kobling mellem datalg og business kode, heller ikke den smarteste løsning.

Det er derfor jeg efterspørger, om der findes en .NET way at lave tingende på.

Med venlig hilsen

Anders

Det er jo ikke så meget en .NET ting men mere generel design.

Rent konkret kan du angive i et argument til ExecuteReader at den skal lukke
connection når den er færdig med at Read'e.

Hvis opdelingen mellem bussiness logic og data access skal være pæn så skal
dun undgå at bruge System.Data... klasser til at flytte data med.

Ja okay det er mere et design spørgsmål, det har du ret i.

Det var smart at det kan angives på readeren.

Hvad mener du med at jeg ikke skal bruge System.Data dvs. helt undgå at benytte datareadere eller datasets?

DataReader er helt fint - internt i data access layer - men fra en puristisk
synsvinkel bør interfacet mellem business logic og data access ikke bruge
den slags database specifikke klasser

Data readeren er ikke så slem. Det er værre med datasættet der indeholder en ofline kopi af databasen.

Jeg giver point på dit svar med at en datareader kan lukkes, men skal sidst lige høre om der er andre forslag til en god model jf. overstående.

en data reader kan ikke serialiseres

en data reader er specifik for en bestemt slags data opbevaring

og et svar

Fint nok.

okay, men det får jeg nu alligevel ikke brug for :-)

tid at acceptere svaret ?

så lad gå :-)