Her beskrives en måde at lave et data access layer (DAL) ved hjælp af typed dataset igennem vs.net.
Jeg kan sagtens se fordelen, rent udviklings mæssigt, ved at gøre det på denne måde det er hurtigt og nemt at gå til, men er det nogen fordel at benytte sig af denne fremgangs måde frem for selv at lave en klasse med diverse metoder til at trække data fra databasen ved hjælp af datareaders istedet for dataset ?
Man skal skrive mindre kode for at bruge typed data set end at lave sin egen objekt model (bruge generelle collections gerne typesafe af egne klasser).
Til gengaeld synes jeg at det typed data set er lidt for knyttet til databasen.
Jeg har aldrig brugt et typed data set. Men hvis jeg skulle bruge det ville jeg kun bruge det PL-DAL og BLL-DAL men aldrig PL-BLL. Og jeg ville kun bruge det til lille-mellem projekter ikke til store-meget store projekter.
Men det er kun min personlige smag/fornemmelse.
Der er ikke nogen endegyldig sandhed for den slags spoergsmaal.
Og jeg kan kun opfordre dig til at proeve lidt forskelligt og finde ud af hvad din menining er.
Og så er stort set alle de projekter jeg laver opbygget af forskellige selvstændige moduler således at jeg kan tilpasse behovet til de forskellige projekter hvilket gør at modulerne for sig selv ikke er specielt store.
Ok, det var også mere for at høre nogle holdninger til det, men der er ikke meget der tyder på at der mange der benytter sig af denne fremgangs måde *GGG*
Det er jo for det meste dig der byder ind på disse spørgsmål ;o)
Som sagt i tidligere tråde om dette emne så har jeg benyttet mig af metoden med en Database-hjælpe klasse, DAL klasse, BLL klasse, Info/entity klasse og PL som virker ganske fint. Men der er jo ikke noget i vejen for at udvide horisonten ;o)
Det kan også i perioder virke voldsomt med alle disse klasser når modulerne ikke er ret store, men jeg får da i det mindste en rød tråd i det hele som er nem at gå til hvis jeg skal ændre/tilføje ting til modulerne.
Og med den tråd du henviser til + en række andre jeg har læst er det jo netop et spørgsmål om smag, samt en indsigt hvad der arbejder bedst i de forskellige senarier man nu måtte blive stillet for.
Det eneste jeg stadigt ikke helt ser nogen fordel i er den famøse factory klasse i mine DAL og BLL klasser. Den sørger for, som du tidligere har skrevet, at adskille mine lag helt :
Public Class f_Factory Public Shared Function LoadClass(ByVal Type As String) As i_Interface Select Case Type Case "hent_class" Return New c_Friend Case Else Return Nothing End Select End Function End Class
Public Interface i_Interface '--- en række metoder End Interface
Friend Class c_Friend '--- en række metoder End Class
Kan du komme med en fornuftig redegørelse for hvorfor jeg skulle bruge den factory klasse fremfor bare at kalde mit interface ?
det er vigtigt for vedligehold at koden er nem at overskue og gennemskue men den egenskab er langtfra kun afhaengig af antal linier kode - flere linier velstruktureret kode kan nemt vaere nemme at forstaa end faerre linier kryptisk kode
og kode lever ofte laengere end oprindeligt planlagt - selvom genbrug i anden kontekst maaske ikke er planlagt naar koden skrives, saa sker det tit at behovet for det opsaar hen af vejen
Se nu tror jeg 5 øren faldt med den factory klasse, det tog sq oxo sin tid, det gør jo klart livet lettere ikke at skulle ændre noget i andre klasser bare fordi man ændre én klasse.
Oceaner af tid har jeg ikke, men pga. en operation her på fredag får jeg 14 dage hvor jeg ikke må lave en døjt, så det er jo en oplagt mulighed til at få kigget lidt på de forskelligr ting ;o)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
