det virker i hvert fald mere færdigt end mange andre O/R mappere, men bærer selvfølgelig også en smule præg af trods alt at være den første version. Umiddelbart ville jeg ikke være mange for at bruge det i produktions-miljøer - i hvert fald bruger jeg det :)
Syntes ikke det er klart, vi bruger det selv nu i en vb6 til .NET konvertering, og må indrømme at vi ville have været mere glade for en ren ADO løsning. Men linq er sikkert genialt når 4.0 kommer ud;)
MS har releaset det i non-beta => klar til produktion
vi bruger af princip aldrig første version og developere skal først lege med det i et år inden det accepteres og derefter går der endnu et år fra projekt start til det går i drift => ikke klar til produktion
Lidt samme indtryk jeg har fået af at læse lidt rundt på nettet. "Linq to sql" virker som et mere færdigt produkt (med de begrænsninger det selvfølgelig har i forhold til EF). Jeg må prøve at lege lidt med det, og så vente på næste udgave. Desværre har Microsoft jo en meeeeeget lang udgivelses-periode.
Ellers må jeg kigge lidt på nHibernate - der er vist også ved at komme noget linq to nHibernate.
Har selv rigtige gode erfaringer med SubSonic, men ville gerne over i et miljø, hvor jeg kunne bruge noget LINQ. Har godt set at der er noget LINQ på vej via SubSonic 3.x, men syntes ikke det preview1 der er udkommet virker til at være noget specielt.
"Linq2object" er da selvfølgelig noget man fint kan bruge i sin kode, og det stoler jeg naturligvis 100% på. Jeg er heller ikke i tvivl om at når man laver noget med f.eks. "Linq to Entities" og det compiler, så skal det nok virke i produktion også, men der er bare andre faktorer man skal tage hensyn til.
- Er det nemt at vedligeholde? Jeg syntes f.eks. det er et helvede at opdatere sin model eller database i Linq2sql, da alle ens ændringer forsvinder hvis man vil indlæse sin db igen. (Igennem Visual Studio). Det er ikke fedt hvis man har 100+ klasser/tabeller.
- Er det fleksibelt nok? Kan man modellere de objekter som man ønsker eller er man bundet til f.eks. "Type pr. table" eller lign. Jeg arbejder f.eks. meget med "localized objects", hvilket betyder at jeg f.eks. har en produkt-tabel i min DB med stam-data, og så en tabel med informationer pr. sprog. Nogle ORM-systemer har meget svært ved at mappe de 2 informationer sammen til én entitet.
det er i mine øjne et meget smalt succeskriterie at køre med hvis man går efter om det kan compile eller ej - der er også spørgsmål om performance samt ting som ibleif er inde på, fx vedligeholdelse og fleksibilitet.
Keyzer : det var selvfølgelig en halv spøg... "it compiles, ship it"
Performance er helt i top, og vil kun blive bedre idet Microsoft kan opgradere compileren, uden at du er nødt til at genskrive (hele) din Linq for at opnå en performance update... gælder især under udviklingen af PLINQ og Parallel
jeg vil påstå at LINQ er nemmere at vedligeholde end SQL, idet man har sin ORM tæt på koden... hvis man har arkitekturen i orden, og kun tilføjer attributter, går koden aldrig i stykker.
sådan har vi arbejdet nu i ½ år på et Silverlight-LINQ-WCF projekt... og det kører hammer godt og er 'nemt' at strikke videre på.
problemet er bare, at man ikke altid kan nøjes med at tilføje attributter - der er ingen tvivl om at LINQ kan hjælpe ufattelig meget i rigtig mange projekter, men hvad sker der når man kommer ud i apparte situationer, er det pågældende valg af mapper så gearet til det eller måske for låst?
Der er også mange andre ting at tage hensyn til - lige nu sidder der nok rigtig mange og eksperimenterer med EF men materialerne kommer først i december/start næste år og hvor meget skal man tro på de best-practises der ligger rundt omkring på nettet - man kunne formentlig spare en masse tid hvis ikke man var først ude (men så ville man selvfølgelig heller ikke være først).
Tak for gode inputs alle sammen. Har besluttet mig for at holde mig til SubSonic lidt endnu.
// Ibleif
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.