31. marts 2005 - 11:23Der er
10 kommentarer og 2 løsninger
Hvordan gør jeg DataGrid / ADO.Net objektorienteret
Hej,
gennem mit studie programmerede jeg Java. Her arbejdede vi med view-controller-model filosofien. Jeg forklarer med et lille eksempel:
Jeg har 3 klasser: GUICustomer ControllerCustomer Customer
Brugeren trykker på knappen "hent alle kunder" og dette event kalder metoden ControllerCustomer.hentKunder(). ControllerCustomer.hentKunder() laver select * from customer i databasen og genererer et Customer array. ControllerCustomer kalder metoden GUICustomer.setCustomers(Customer[]) som sørger for at kunder bliver vist i GUI'en.
Så langt så godt.
Hvis man kigger på C# / ADO.net kan jeg lave det samme med en DataReader. Men der er jo også alternativet DataGrid. Umiddelbart synes jeg dog at den objekt orienterede tankegang ryger en smule idet man ikke her vil arbejde med objektet Customer, men arbejde direkte i DataGrid og opdatere databasen ved hjælp af DataGrids metoder. Er det korrekt forstået eller er det mig der misforstår noget.
Det er MVC jeg tænker på. Men hvor kommer M ind i billedet. Det er sikkert min forståelse der er noget galt med men når jeg bruger DataGrid bruger jeg en DataAdapter, fylder et untyped DataSet og binder dette til min grid. Hvis vi bruger eksemplet fra før så mister jeg vel model klassen Customer, idet man bare ændrer i griden.
Ja den er jeg med på, men med udgangspunkt i mit ovenstående eksempel, bliver der ikke behov for modelklassen Customer. Og så går man vel på kompromis med den objekt orienterede tankegang - at modellere objekter der kan relateres til virkeligheden.
det er rigtig nok.. men så kan du jo lave et typed dataset, eller binde en Customer-collection til dit datagrid. Ingen siger du SKAL bruge et dataset, selvom det det da nok er det der fungerer bedst.
Typed dataset -> er det ikke baseret på tabellen og ikke en model klasse
Customer collection -> så mister jeg vel en del af DataGrid funktionaliteten eller hvad? jeg tænker her på oprettelse af nye kunder og ligeledes opdateringer mv.
Jeg siger ikke at modellaget SKAL være baseret på klassen customer, men vil bare gerne vide om tanken med datagrid er at man dropper klassen der modellerer virkeligheden og istedet tilgår disse data direkte via DataGrid/DataSet.
et typed dataset er lidt en blanding mellem et normalt dataset og så din customer-klasse. Du har mulighed for at definere hvilke typer de enkelte kulonner skal være, og implemetere kunde-relaterede metoder. I bund og grund er det dog ikke andet end en klasse der nedarver fra Dataset-klassen.
Det er rigtigt at Datagriddet har rigtig mange dejlige funktioner, men de er næsten alle mindet på brugen af Dataset/Datatable/Dataview. Det er svært at lave et så stort og genenmført komponent som datagriddet er hvis man ikke ved hvilken datastruktur den skal basere sig på. Jeg synes da det er fint at man også kan bruge almindelige IList-objecter som objecter, men så mister man rigtig nok noget af funktionaliteten.
Men så slemt er det nu heller ikke. Du kan sagtens udvide datagriddet til at understøtte oprettelse og opdatering af dine egne objecter. Det er ikke værre end at subclasse datagriddet og evt. metoder den måtte bruge.
Ok. Jeg bliver lidt klogere. Konklutionen må være - Brug DataGrid og drop den "rene" MVC hvad denne del angår. Alternativ kan man lave noget med en Collection, men det fjerner en del funktionalitet fra DataGrid.
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.
