c# Linq wrapper

[Verwijderd]

Momenteel ben ik aan het spelen met Linq, wat eigenlijk goed bevalt. Het enige nadeel vind ik alleen dat enkel Microsoft SQL Server ondersteunt wordt. Heeft er iemand ervaring met een goede linq wrapper voor een andere database?

Ik heb al een wrapper voor sqlite geprobeerd, maar ben er niet echt tevreden over. Ik krijg vage fouten... die volgens de forums vaak komen omdat deze wrapper nog in ontwikkeling is. Graag jullie ervaringen! :-)

[gorgi_19]

LinQ to XML bestaat ook

Maar kijk eens naar bijvoorbeeld een O/R mapper als LLBLGen, afaik ondersteunt die ook LinQ

[Verwijderd]

Ja... maar allemaal XML bestanden gebruiken is ook niet ideaal :-)

[EfBe]

Zie signature

[Fiander]

Ik gebruik eingenlijks LinQ alleen voor objecten.
Voor databases meestal een TableReader / DataTable

beetje ouderwets mischien, maar het voldoet.

[whoami]

Hmm, LINQ is meer dan LINQ to SQL (of wat de exacte naam ook is).
Als je via LINQ je DB wilt aansprekn, zijn er verschillende opties. De meeste O/R mappers ondersteunen het (LLBLGen zoals hier al gezegd; voor NHiberrnate is men ook bezig, ...).
Je kan natuurlijk zelf ook een eigen linq provider maken ....

[bastv]

http://groups.google.com/group/dblinq

zelf geen ervaring mee

[EfBe]

whoami schreef op maandag 20 oktober 2008 @ 09:29:
Hmm, LINQ is meer dan LINQ to SQL (of wat de exacte naam ook is).
Als je via LINQ je DB wilt aansprekn, zijn er verschillende opties. De meeste O/R mappers ondersteunen het (LLBLGen zoals hier al gezegd; voor NHiberrnate is men ook bezig, ...).

Eigenlijk ondersteunen maar heel weinig o/r mappers Linq. De meesten roepen het wel, maar komen niet veel verder dan simpelere selects. Het kost nl. nogal wat werk om volledig Linq te supporten (kostte mij 8 maanden full time development). Als ik eerlijk mag zijn is onze linq provider de enige naast die van Microsoft die linq volledig implementeert.

Het hangt er vanaf wat de topicstarter precies wil. Linq is idd de naam voor het principe dat je kunt queryen in code: is de source een IEnumerable<T> dan krijg je linq to objects, is het een IQueryable<T> dan moet de source's provider de query afhandelen (want wordt dan gecompileerd in code die een Expression tree opbouwt). Dit betekent dus dat die provider dat ook moet kunnen, anders krijg je problemen at runtime. Het nadeel voor topicstarter is nu dat die provider specifiek is voor de O/R mapper die gebruikt wordt: dus gebruik je Linq to Sql, dan krijg je de provider van Linq to Sql, maar kun je niet een andere O/R mapper gebruiken. Gebruik je de onze, dan kun je niet Linq to Sql gebruiken etc.

Werken met data is meer dan data ophalen: je entity classes gebruik je verder in je applicatie, de services geboden door de o/r mapper ga je gebruik van maken, en niet te vergeten: data inserten, deleten en updaten, hoe wil je dat gaan doen. Het is dus belangrijk dat de topicstarter hier over nadenkt: is Linq to Sql precies hoe ik wil werken, dan is het wisselen van de linq provider dus ingrijpender dan alleen het kiezen van een andere o/r mapper: andere dingen wijzigen ook.

[Verwijderd]

Ik wil het gebruiken voor Linq to Sql. Maar veel ervaring heb ik er nog niet mee, ik ben alle mogelijkheden aan het onderzoeken. Data ophalen lukt over het algemeen met de wrapper die ik probeerde, maar inserten ging al een stuk lastiger.

Eerst ga ik nog wat ervaring op doen met Linq to Sql icm MS SQL. Want dan weet ik (vrij) zeker dat mijn code verkeerd is bij errors. Daarna ga LLBL-gen eens proberen. Bedankt voor jullie feedback in ieder geval!

[bastv]

voor een sql database zal ik ook eens kijken naar ADO.NET Entity Framework.
En dan linq to entities, ben ik de laatste tijd ook mee bezig en bevalt goed