FAQ |
Kalender |
2010-03-13, 09:10 | #1 | ||
|
|||
Har WN som tidsfördriv
|
I en ann tråd kom LINQ upp som tips. Jag tänkte ge det ett chans och tycker det är trevligt men blir ändå inte helt nöjd. Antingen ser jag inte storheten eller så passar det inte mig. Vill gärna höra era åsikter och vad ni tycker är bra eller dåligt med LINQ.
Ïntellisense är klart trevligt och ett stort plus men om jag ändrar i databasen så uppdaterars inte dbml-filen automatiskt och det finns ingen refresh-knapp eller liknande utan jag får ta bort tabellen och sen lägga till den igen. Performance: LINQ är slöare vanlig SQLDataset. Är vinsten av att det är lätt programmerat större än att själva applikationen blir slöare? Vad tycker ni? En av alla länkar: http://www.devtoolshed.com/content/p...selects-part-1 Vilka mer fördelar och nackdelar kommer ni på? Tipsa gärna på bra länkar om LINQ. Just nu läser jag igenom http://msdn.microsoft.com/en-us/library/bb386976.aspx samt en PDF-bok om LINQ som jag fick av Microsoft. |
||
Svara med citat |
2010-03-13, 18:16 | #2 | ||
|
|||
Har WN som tidsfördriv
|
Jag tycker LINQ är trevligt, intellicense kan du ju få utan LINQ och är ju absolut ingen anledning till att satsa på LINQ. Däremot så behöver du ju aldrig behöva bekymra dig om SQL syntax längre när du programmerar, du kan ju uppdatera objekt som i sin tur genererar SQL syntax, vilket gör det trevligt att programmera.
LINQ är dock långsammare eftersom det av naturliga skäl skapar en overherhead. Du kan inte heller styra på vilket sätt LINQ ska skapa SQL Frågor (vilket är en del av vitsen) så har du program där du MÅSTE skriva en SQL fråga på ett visst sätt för att det ska gå snabbt så är det inte säkert att LINQ är ett bra alternativ. |
||
Svara med citat |
2010-03-13, 19:58 | #3 | ||
|
|||
Medlem
|
Linq to SQL är inget jag gillar direkt. Föredrar i sådana fall Entity Framework, vilket är det som Microsoft satsar på. Kör du med .NET 3.5 SP 1 eller senare så rekommenderar jag absolut att du kör med Entity Framework.
I Entity Framework 4.0 (kommer i .NET 4.0) så har du även möjlighet att skapa POCO-klasser baserat på modellen, vilket gör att du kan mappa domänobjekt direkt mot databasmodellen. Entity Framework har precis som Linq to SQL en Linq-provider. Det gör att du kan använda i stort sett samma frågor för databasanropen. Vad gäller prestanda så bör du självklart cacha så mycket som möjligt. Jag själv har kört en hel del med Entity Framework och har inte haft några problem med prestandan. Om du är intresserad av att veta hur det fungerar i bakgrunden så har jag skrivit om det här: http://weblogs.asp.net/mikaelsoderst...ion-trees.aspx Har även en del andra poster som tar upp Entity Framework. |
||
Svara med citat |
2010-03-15, 08:50 | #4 | ||
|
|||
Har WN som tidsfördriv
|
Tack för era inlägg, ska titta vidare på både LINQ och Entity Framework och se vad jag tycker. Länkar är alltid välkomna.
|
||
Svara med citat |
2010-03-18, 00:31 | #5 | |||
|
||||
Flitig postare
|
jag kör mycket linq to objects, på så sätt kan jag slippa massa evinnerliga foreach loopar i min kod när man ska filtrera o hitta objekt i listor tex.
|
|||
Svara med citat |
2010-03-18, 07:17 | #6 | ||
|
|||
Har WN som tidsfördriv
|
Där har jag inga problem eftersom jag ställer exakta SQL-frågor mot databasen. Eller rättare sagt, jag har stored procedure (SP) som jag ropar på som i sin tur hämtar det jag vill ha. Jag får tillbaka det jag vill ha och inget annat. Det blir visserligen en hel del SP men många SP klarar flera olika typer av frågor så det blir i alla fall inte oöverskådligt många.
|
||
Svara med citat |
Svara |
|
|