Vad tror vi om linq då?

Jag tycker det verkar mycket vettigt om man använder det på rätt sätt,
dock tror jag att många kommer tycka att det är fräckt och använda det på fel sätt.

Däremot så innehåller NHibernate så mycket mer än vad Linq erbjuder vad jag har fattat det som.

Jag kommer skippa min eget skrivna OR-mapper, som iprincip bara hämtade/updaterade data från databasen. Det löser LINQ bra mycket bättre och framför allt på ett snyggare sätt. Däremot kommer jag lägga tid på att skapa en riktigt bra collection som man kan göra det mesta man vill med en collection.

- M

För det första bör det sägas att Linq (Language Integrated Query) inte konkurrerar med or-mappers. Linq är bara (inte så bara) en språkutökning som tillåter queries på objekt, men det har ingen arkitektur för persistence. Linq motsvarar alltså snarare NHibernates HQL eller Wilsons (m.fl) OPath, men gör det på ett sätt som är helt integrerat i programmeringsspråket. Det finns dock ett sidoprojekt som heter Dlinq (numera "LINQ to SQL") som kopplar ihop Linq:ade klasser med en databas, och dessutom ett ytterligare projekt som heter LINQ to Entities + ADO.NET Entity Framework som är en mer komplett OR-mapper (och mer därtill).

Är Linq bra?

Jag tycker det. Linq är överlag mycket snyggt och Microsoft (som har lyxen att kunna erbjuda något sådant, eftersom de sitter på kompilatorarkitekturen) har lyckats skapa en query-arkitektur som är mycket användbar. Man kan skapa egna modeller och system som kan bli "frågbara" genom Linq. Det behöver inte vara en databas, utan det kan lika gärna vara mot t.ex. en webservice eller ..... NHibernate (Ayende jobbar redan på Linq for NHibernate)

Är Linq to SQL bra?

Mnja. Det är antagligen tillräckligt bra för att fler ska fatta att OR/M-arkitekturer är rätt väg att gå (därmed inte sagt att det alltid är det, men ofta....ofta som fan), men det är verkligen inte bättre än t.ex. NHibernate eller Wilson ORMapper. Den tekniska implementeringen lämnar mycket att önska. Det faktum att det är Microsoft som släpper teknologin betyder dock antagligen mer för att många ska börja använda det, och förhoppningsvis så blir det i alla fall ett steg ifrån TableAdapters och annan pajasteknologi. Tyvärr är det endast för SQL Server.

Linq to SQL kan inte ersätta NHibernate et al. på långa vägar, men det är en bit på vägen.

LINQ to Entities + ADO.NET Entity Framework

Detta ramverk är en annan femma. Det är märkligt och aningen irriterande att två olika arbetsgrupper inom Microsoft jobbar mot liknande mål och först långt in i projekten inser att det kan ha nytta av varandra. EF (Entity Framework) är ett komplett OR/M-ramverk med en rätt massiv abstraheringsarkitektur. Stödet för Linq kom till i efterhand, men det bör fungera bra.

Kommer NHibernate att ha något existensberättigande?

Ja verkligen. NHibernate är än så länge en mycket mognare teknologi, med åratal av användarfeedback (från både .NET och Java-världen) bakom sig. Dessutom finns det alla möjligheter att nyttja NHibernate i ett Linq-scenario. Det faktum att NHibernate är en bättre teknologi behöver dock inte innebära så mycket, eftersom många utvecklare och organisationer bara bryr sig om saker som det står Microsoft på. Microsoft marknadsför dessutom hela konceptet som om det vore något helt nytt, och nämner inte att det finns existerande lösningar.

Sammanfattningsvis...

Linq, frågespråket, är fina grejer. Mycket användbart! Linq to SQL och EF ger däremot inte så mycket nytt och för mig som redan investerat tid i att bli bra på existerande OR/M-ramverk så finns det inte något som lockar, förutom den integration med Visual Studio som kommer att erbjudas.

emission skrev:

För det första bör det sägas att Linq (Language Integrated Query) inte konkurrerar med or-mappers. Linq är bara (inte så bara) en språkutökning som tillåter queries på objekt, men det har ingen arkitektur för persistence. Linq motsvarar alltså snarare NHibernates HQL eller Wilsons (m.fl) OPath, men gör det på ett sätt som är helt integrerat i programmeringsspråket. Det finns dock ett sidoprojekt som heter Dlinq (numera "LINQ to SQL") som kopplar ihop Linq:ade klasser med en databas, och dessutom ett ytterligare projekt som heter LINQ to Entities + ADO.NET Entity Framework som är en mer komplett OR-mapper (och mer därtill).

Är Linq bra?

Jag tycker det. Linq är överlag mycket snyggt och Microsoft (som har lyxen att kunna erbjuda något sådant, eftersom de sitter på kompilatorarkitekturen) har lyckats skapa en query-arkitektur som är mycket användbar. Man kan skapa egna modeller och system som kan bli "frågbara" genom Linq. Det behöver inte vara en databas, utan det kan lika gärna vara mot t.ex. en webservice eller ..... NHibernate (Ayende jobbar redan på Linq for NHibernate)

Är Linq to SQL bra?

Mnja. Det är antagligen tillräckligt bra för att fler ska fatta att OR/M-arkitekturer är rätt väg att gå (därmed inte sagt att det alltid är det, men ofta....ofta som fan), men det är verkligen inte bättre än t.ex. NHibernate eller Wilson ORMapper. Den tekniska implementeringen lämnar mycket att önska. Det faktum att det är Microsoft som släpper teknologin betyder dock antagligen mer för att många ska börja använda det, och förhoppningsvis så blir det i alla fall ett steg ifrån TableAdapters och annan pajasteknologi. Tyvärr är det endast för SQL Server.

Linq to SQL kan inte ersätta NHibernate et al. på långa vägar, men det är en bit på vägen.

LINQ to Entities + ADO.NET Entity Framework

Detta ramverk är en annan femma. Det är märkligt och aningen irriterande att två olika arbetsgrupper inom Microsoft jobbar mot liknande mål och först långt in i projekten inser att det kan ha nytta av varandra. EF (Entity Framework) är ett komplett OR/M-ramverk med en rätt massiv abstraheringsarkitektur. Stödet för Linq kom till i efterhand, men det bör fungera bra.

Kommer NHibernate att ha något existensberättigande?

Ja verkligen. NHibernate är än så länge en mycket mognare teknologi, med åratal av användarfeedback (från både .NET och Java-världen) bakom sig. Dessutom finns det alla möjligheter att nyttja NHibernate i ett Linq-scenario. Det faktum att NHibernate är en bättre teknologi behöver dock inte innebära så mycket, eftersom många utvecklare och organisationer bara bryr sig om saker som det står Microsoft på. Microsoft marknadsför dessutom hela konceptet som om det vore något helt nytt, och nämner inte att det finns existerande lösningar.

Sammanfattningsvis...

Linq, frågespråket, är fina grejer. Mycket användbart! Linq to SQL och EF ger däremot inte så mycket nytt och för mig som redan investerat tid i att bli bra på existerande OR/M-ramverk så finns det inte något som lockar, förutom den integration med Visual Studio som kommer att erbjudas.

Mycket intressant diskussion, jag skulle gärna vilja veta om du "bara" bygger detta på din egen erfarenhet av Linq, NHibernate etc.

Om man tittar runt lite på bloggar så är det många som inte tycker att Entity Framework är moget änsålänge.

Nickemannen skrev:

Om man tittar runt lite på bloggar så är det många som inte tycker att Entity Framework är moget änsålänge.

Anledningen till att det är ofärdigt är för att gruppen som skapade entity framework fått lägga det på is till förmån för LINQ 2 SQL om jag förstått det hela rätt. De ville inte skapa kaos för oss programmerare.

Jag läste på någon blogg att det inte kommer hända så mycket på entity framework det närmsta året.

Fredde Mannen skrev:

Mycket intressant diskussion, jag skulle gärna vilja veta om du "bara" bygger detta på din egen erfarenhet av Linq, NHibernate etc.

Det vill jag nog påstå, men sannolikt har min åsikt färgats eller åtminstone validerats av det jag läst på diverse bloggar och forum.

Själv har jag halkat in på NHibernate som så många andra och gillar det skarpt! :)
Underlättar ju barnsligt mycket när gäller att koppla (joina) ihop klasser bla.

Så behöver vi egentligen Entity Framework?
Vad kan det tänkas innehålla som inte NHibernate inte redan innehåller?

Det är väl inte officiellt släppt än tror jag (rätta mig om jag har fel) men NHibernate får ju snart också LINQ stöd! Ännu mindre anledning att vänta på EF! :)

Jag tycker att den stora fördelen med LINQ och Entity Framework är att det är integrerat i Visual Studio. Entity Framwork kanske inte funkar tillfredställande än, men LINQ gör det garanterat.

Sen är det som vi redan har kommit fram till, att man kan joina flera källor. Man kan t.ex. hämta data från en service och annan data från en lokal databas och sedan joina dem. Det tycker jag är ganska coolt.

Det som jag tycker är negativt med NHibernate är att implementationen för .NET bygger på en lastgammal version av Hibernate (2.1). Samtidigt har jag inte jättemycket erfarenhet med NHibernate, så det är bara en liten lös känga till NHib.

Btw, Är det någon med lite LINQ-erfarenhet som kan lösa detta:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2742070&SiteID=1

::m

MikeEast skrev:

Jag tycker att den stora fördelen med LINQ och Entity Framework är att det är integrerat i Visual Studio. Entity Framwork kanske inte funkar tillfredställande än, men LINQ gör det garanterat.

Det kan man tycka, men samtidigt så...

MikeEast skrev:

Btw, Är det någon med lite LINQ-erfarenhet som kan lösa detta:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2742070&SiteID=1

...dyker det ju upp en del nackdelar. Man kan ju tycka att "frameworket" inte borde kompilera och föreslå (IntelliSense) saker som inte kan genomföras, med det är något man måste ha överseende med i ett så stort ramverk som LINQ. Alla providers kan inte klara allt man kastar på dem.

Du måste hämta hem resultatet för att kunna köra en distinct med en IEqualityComparer. Det är fullständigt logiskt (QuertyConvertern kan inte gärna lista ut hur din comparer fungerar, om om den lyckades skulle den ändå behöva skapa en tämligen komplex SQL-sats), men jag kan hålla med om att det ser ut som att det skulle fungera.