Je voudrai savoir quels sont les intérêts de Linq, ou plus précisément, dans quelles circonstances a-t-on intérêt à l’utiliser ?
De ce que j’en ai compris, il permet de requêter finement des objets d’une manière similaire au SGBDR. Par exemple :
[code] public void Example()
{
List customers = GetCustomerList();
DateTime cutoffDate = new DateTime(1997, 1, 1);
var orders =
from c in customers
where c.Region == "WA"
from o in c.Orders
where o.OrderDate >= cutoffDate
select new { c.CustomerID, o.OrderID };
foreach (var order in orders)
{
Console.WriteLine(String.Format("{0}\t{1}", order.CustomerID, order.OrderID));
}
}[/code]
En revanche pour les accès mais surtout les modifications sur les bases de données, qu’en est-il ? Est-ce qu’il est fait pour ça ? ou uniquement pour récupérer des résultats ?
Autre question (naïve ?) mais fait-il parti de ADO.NET ? Et où se situe-t-il par rapport à celui-ci.
Y-aurait-il une sorte de mini SQLENGINE intégré dans le .NET Framework 3.5 ?
Enfin pour ceux qui souhaitent voir a quoi ressemble LINQ il y a une solution dans le répertoire SAMPLES de l’application assez sympa :
%INSTALL%\Samples\1033\CSharpSamples.zip
Dans le zip, c’est dans LinqSamples et ça s’appelle BuildSamples.sln
LINQ en lui meme c’est juste la syntaxe, Language Integrated Query. Apres t’as des mapping vers ce que tu veux, SQL, la dans ton cas une collection, etc. C’est le mapper qui transforme ta query dans la lambda expression equivalente, et la lambda expression peut etre interpretee/traduite dans le langage que tu veux. Par exemple dans ton cas, en simplifiant:
var customers =
from c in customers
where c.Region == "WA"
select c;
est equivalent a
Ceux qui ont fait du lambda calcul et/ou des cours de compilateur reconnaitront certaines bases… Enfin apres t’as par exemple un LINQ to SQL qui fait un mapping vers SQL (par Ado.Net apriori)
T’as un LINQ to Entity qui fait un mapping vers un O/R mapper
etc.
Ca gere ce que ton mapper gere, mais ouai y a pas de raisons, update, read, etc.
Si tu veux voir comment ca fonctionne sous le capot, abuse de reflector, et regarde ce qui est généré quand tu écris des requêtes sur des IQueryable et IEnumerable. Pour bien comprendre Linq, Linq to SQL, Linq to Nespresso etc., le meilleur moyen est déjà de comprendre comment fonctionne le compilateur.
Linq to Nespresso! Reve!
Linq to Entity est cense etre le O/R mapper, mais on rentre carrement dans la guerre de religion sur la place des objects pur ou pas dans l’acces au un “persistance storage” huhu. Les O/R mapper dans mon experience c’est plus souvent des usines a gas qui conduisent a un “over-engineering” qu’a autre chose, mais bon j’en ignore pas l’utilite dans certains cas non plus. C’est pour ca que je trouve ca pas mal qu’au niveau “simple” il y ait LINQ to SQL comme un truc lightweight et si tu veux le truc balaise t’as LINQ to Entity ou une solution third party. Enfin c’est flexible quoi, c’est bien.
Y’a une autre chose à prendre en compte, Linq to SQL dans sa première version n’est pas extensible : les tierces parties ne peuvent pas proposer de providers, alors que Linq to Entity le sera (et au passage, Entity Framework a été repoussé à “quelques mois après la sortie du Framework 3.5”)
[quote=“GloP, post:6, topic: 34877”]Linq to Nespresso! Reve!
Linq to Entity est cense etre le O/R mapper, mais on rentre carrement dans la guerre de religion sur la place des objects pur ou pas dans l’acces au un “persistance storage” huhu. Les O/R mapper dans mon experience c’est plus souvent des usines a gas qui conduisent a un “over-engineering” qu’a autre chose, mais bon j’en ignore pas l’utilite dans certains cas non plus. C’est pour ca que je trouve ca pas mal qu’au niveau “simple” il y ait LINQ to SQL comme un truc lightweight et si tu veux le truc balaise t’as LINQ to Entity ou une solution third party. Enfin c’est flexible quoi, c’est bien.[/quote]
Faut pas lancer des débats comme ça Glop B)
J’aurais tendance à dire que philosophiquement parlant, l’O/R mapper est vraiment dans l’esprit objet. Ceci dit, je pense qu’on est tous d’accord pour dire que c’est une plaie sans nom à écrire, et que ça demande un investissement de base assez conséquent qui reste le même qu’on soit sur un petit ou un gros projet. Ceci dit, l’émergence de framework tel que NHibernate pour ne pas le citer, ou Entity Framework maintenant, a tendance à retirer 90% du boulot nécessaire. Ca ne veut pas dire pour autant que l’utilisation d’un O/R mapper devient LA solution à utiliser dans tous ses projets, clairement pas, tout dépend du contexte bien entendu.
Bah on est plus ou moins d’accord je crois. Moi j’ai tendance a penser que c’est futile de penser qu’on peut regler ce probleme de maniere generique et qu’il y a pas de “silver bullet”, qu’il en y an jamais eut, et qu’il y en aura jamais. Que les gens qui disent “ca ca resoud tous les cas” c’est des mecs du marketting qui ont jamais codé B). Encore une fois ca veut pas dire qu’il y a pas des solutions qui peuvent marcher dans plein de cas et qu’on va pas progresser pour avoir des solutions a la fois simple et qui couvrent 90% des cas. Enfin c’etait plus philosophique qu’autre chose comme remarque B)