27. oktober 2008 - 21:49Der er
10 kommentarer og 1 løsning
Udvide LinQ Entities
Jeg har nu leget en masse med LinQ, og er lidt i tvivl om hvordan man griber det an på den bedste måde. Det er ikke ligefrem Microsofts stil at lave en "Best practice" beskrivelse.
Men hvordan benytter man normalt de entities som linq genererer? Tænker her på, hvis man gerne vil tilføje nogle metoder til dem? Gøres dette normal via nogle Manager-klasser i "business-laget" eller kan man udvide sine entities på en eller anden måde? Det er vel lidt spild af tid/arbejde at lave nogle nye entity-klasser som man egentligt bare mapper værdierne fra linq-entities over?
Du kan jo evt. lave en partial class hvis det er det du mener. Hvis du f.eks. vil knytte nogle ekstra metoder til din Customer entity (eller hvad du nu har fra din datacontextfil), så kan du jo lave:
Interessant svar montago! Helt sikkert noget af det jeg søger.
men her tænker jeg også på hvis man vil lave en struktur hvor man nedarver de forskellige linq entities fra hinanden osv. Kender godt metoden som man laver nedarvning i selve linq-to-sql, men synes det er en ret dårlig metode når man ser på databasedesign.
Sorry hvsi det er lidt kringlet forklaret. Det jeg gerne vil have, er helt normale ting som man bruger i object orienterede sprog. Nedarvning mellem klasser, interfaces osv osv. Dette får man jo ikke out of the box med linq entities.
I de projekter jeg sidder med lader vi Linq være Linq og modellere vores objekter ved siden af -- som regel som containers eller som funktionsobjekter - hvor disse kan arve og implementere interfaces...
Linq2sql skal jo så kun bruges til at snakke med databasen.
Linq2objekt kan så sagtens benytte sig af de objekter vi har defineret...
jeg kan ikke se hvorfor du vil gå den anden vej rundt :-)
Ved godt det er et gammel emne, men har lige et hurtigt spørgsmål. Synes jeg har tænkt og tænkt og kan ikke finde den optiamle måde at lave egne objekter "ovenpå" linq-entities. Er det simpelthen bare wrapper-klasser hvor der bliver mappet linq-properties over i custom-objekterne? Bliver det ikke hurtigt meget slavearbejde hvis man har en masse one-to-many relations osv på linq entiteterne?
Med hensyn til substansen, så er data klasser til data og ikke til business logic.
Hvis man har et behov for at lave klasser med samme data i et lag ovenover, så er det tit et tegn på at laget ovenover er et overflødigt passthrough lag. Og selvom det ikke er tilfældet så er det ihvertfald en meget tæt kobling mellem ens business services og ens database struktur.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
