Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
LINQ ou ADO.NET
Bonsoir,
je commence a découvrir ado.net et linq, j'ai compris que ado.net permet l'accès aux bases de données en mode Connecté/ deconnecté.
mais lorsque je suis passer pour voir ce qu'est LINQ, a ma grande surprise ; lui aussi permet aussi d'accéder a des bases de données;
si c'est le cas, lequel choisir?
j'ai lu plein d'article sur le sujet,et difficile de comprendre ce que offert linq;
un petit éclaircissement serait le bien venu et merci d'avance.
ni l"un ni l'autre... lol
en réalité, ADO.NET regroupe toutes les technologies de connectivités aux DB de dotnet.
ADO.NET est une espèce de méta-framework qui en regroupe plusieurs.
parmi ce qui compose ADO.NET on trouve ADO.NET 2.0 pour dotnet 2.0.
on trouve Linq To SQL, qui signe l'apparition de Linq, pour dotnet 3.0
puis de Entity Framework v1 avec dotnet 3.5 SP1,
et maintenant de Entity Framework v2 (ou v4) avec dotnet 4.0.
En réalité, quand tu parle de Linq, il faut préciser, mais il ne faudrait plus tendre à utiliser les anciens frameworks ADO.NET pour des versions anciennes de Dotnet.
En fait il vaudrait mieux que tu te concentre sur Entity Framework, dans sa version 1 et 2...
Aujourd'hui dans le domaine du particulier, tu peux développer en dotnet 4 sans problème et utiliser EF2 et les nouveaux modèles comme T4 pour améliorer le design, mais si tu programme pour l'entreprise, il y a encore fort à parier qu'il faille rester sous dotnet 3.5 et ce pour des raisons évidentes de pérénité, de migration progressive des infrastructures et également car dotnet 4 n'a pas assez de recul, pour que les entreprises qui code pour des entreprises lui fassent totalement confiance.
(on en reparlera dans 6 mois quand il aura une bonne liste des mises à jours à son effectif)
Avec Entity Framework tu entendra parler de Linq to Entities, qui est l'extension Linq pour Entity Framework, voilà pourquoi je te disais de spécifier... car Linq to SQL n'est plus utilisé, mais on a également Linq To Object pour utiliser l'écriture linq partout dans le code et aussi Linq To XML qui a nettement améliorer la prise en charge de XML dans les applications Dotnet.
Pour faire simple l'ancien modèle ADO.NET permettait d'accèder aux bases de données via des classes DataSet et DataTable qui représentaient respectivement des collections de tables et des tables SQL, en mémoire dans l'environnement dotnet.
Passons sur cet aspect mais il ne va pas du tout avec les concepts de programmation objet et nécessitait d'écrire des couches d'accès aux données douloureuses et pénibles, et particulièrement longues, et c'était à toi de gérer le mapping O/R.
Linq to SQL a permis de faire un bon en avant, et d'adopter une méthodologie autre en se rapprochant petit à petit de ce que permettait déjà de faire le framework tiers NHibernate.
On a commencé alors à entrer dans le monde du Mapping O/R (Objet-Relationnel) ou comment associer dans ton programme des objets, aux entités relationnelles de SQL (les tables)
Puis est né Entity Framework v1, très nette évolution de Linq To SQL avec une véritable flexibilité dans les possibilités des mapping et une grande innovation par rapport à Linq To SQL.
Sous Linq To SQL tout le code de persistance avec la base de données, était directement écrit dans les classes Linq To SQL (autogénérées) Elles étaient donc lourdes, indigeste et allaient à l'encontre de la programmation en couche car le modèle métier était parasité par la logique de persistance et l'accès aux données.
Sous EF v1 et v2 seul un fragment de la persistance est présent dans les objets métiers qui refletent ta DB, mais la vraie logique de persistance se situe dans une classe de Contexte.
Ce qui permet d'avoir une première étape de séparation claire et nette des 2 couches, Métiers et logique.
Finalement, c'est chose faite avec EF2 et le modèle T4 sous Visual Studio 2010, puisqu'on arrive enfin à développer en POCO avec EF2, et avoir des classes métiers, des objets refletant ta DB toujours, totalement libre des informations de persistances dédié cette fois au Context.
Ce modèle permet donc de facilement exporter les données au travers de services WCF et des RIA SilverLight 4.
On pouvait le faire avec EF1 mais c'était nettement moins propre, mais cela fonctionnait déjà bien.
Cela dit pour du code autogénéré, on peut se demander pk chippoter et vraiment séparer les couches, mais tant qu'à faire du code propre autant qu'il le soit partout et cela facilite les développement d'architectures N-Tiers.
Pour faire simple si tu as une base de données fonctionnelle avec des données dedans, ouvre un projet et ajoute un ADO.NET ENTITY DATA MODEL et tu le fait depuis une base existante, tu va voir ainsi la machine de guerre se mettre en branle et te créer ton modèle objet à partir du modèle relationnel.
Il vaudrait mieux en général partir du modèle objet pour obtenir le modèle relationnel, mais à défaut...
histoire au moins de voir ce que c'est que cette bête...
une fois cela fait, sans meme parler de T4, POCO et autre, tu peux une fois l'objet de contexte instancié faire par exemple sur Northwind
customers contient alors tous les objets Customer représentant chacun une ligne dans la base à la table Customers.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
de là tu travaille sur des objets et non sur des liste des colonnes non typés.
tu peux donc isoler un des Customers et travailler sur ses propriétés comme son identifiant numérique ... car c'est un véritable Objet, et tu peux également accèder à des listes d'objets en relation avec...
Voilà excuse-moi pour ce roman, mais j'espère avoir répondu au mieux à ta question, avec un historique des technologies pour mieux comprendre les terminologies qui formes cette jungle d'aujourd'hui.
merci beaucoup cinemania pour votre réponse, je commence a comprendre ces concepts ci, mais y'a des parties qui m'échappent:
-code de persistance ( j'ai pas compris ce que ça voulait dire ) donc pas compris l'utilité de l'EF, on peut toujours bossé avec LINQ to SQL? non?;
-T4, POCO : c'est quoi (j'ai cherché a nouveau dans le net sans trouvé la réponse)
oui mais Linq to sql n'est plus développé par MS qui conseille donc d'utiliser EF.on peut toujours bossé avec LINQ to SQL?
Code permettant de sauvegarder ou charger les données dans la base de données.code de persistance
Plain Old CLR Object. C'est à dire des objets qui ne dépendent de rien.POCO
Un exemple de non POCO : avec EF1 il fallait implémenter 3 interfaces de EF.
Fichier permettant de générer du code. Très facile à utiliser avec EF.T4
Exemple T4
0red si tu est persuadé de l'utilité de Linq to SQL, pourquoi ne pas dans ce cas simplement passer à la technologie suivante, qui elle évolue.
Linq to SQL n'a servit que de phase de transition entre ADO.NET ancienne génération avec les DataSet, DataTable et autres joyeusetés, et la nouvelle plateforme Entity Framework.
Techniquement parlant tu peux toujours développer avec n'importe laquelle de ses technologies, elles cohabitent toutes dans dotnet, car les changements de versions ne signent pas l'arrêt d'une technologie pour autant.
Autre détail technologique, Linq To SQL était extrêmement contraignant, en effet, pour utiliser Linq To SQL il fallait impérativement partir de ton modèle relationnel (DB) pour obtenir ton modèle objet, en sachant également que chaque entité (table ou vue) donnait lieu à une entité distincte (objet) dans ton code. Impossible de zapper les tables qui ne devraient pas avoir d'existences et servent uniquement aux liaisons, dans ton modèle objet...
C'est très problématique car tu te retrouve avec des objets sans existence réelle, et totalement en décalage par rapport au métiers qu'ils sont censé décrire, puisqu'ils servent uniquement à modéliser une relation d'arité N-N entre des tables, hors les relations même de type n-n ne sont généralement pas des objets à part entière du modèle objet de données métiers, mais simplement des liaisons plus ou moins complexes, avec des collections.
Il est évident que si la dite liaison dispose de ses propres propriétés, son existence dans le monde objet n'est pas dénuée de sens, mais ce n'est que rarement le cas.
Avec EF tu peux changer cela en définissant séparément, le modèle relationnel d'un coté, le modèle objet de l'autre, et le mapping entre les 2 mondes.
tout ceci se fait sur un ensemble de 3 fichiers xml, regroupés en un seul fichier EDMX si tu utilise l'outil visuel de Visual Studio qui te permettra de créer ton modèle objet depuis ta base de données, où l'inverse si tu a créé ton modèle objet, créer ta base de données associée.
C'est d'ailleurs cette méthode qui devrait plus souvent être retenue, partir du modèle objet pour obtenir le modèle relationnel que l'inverse, c'est d'ailleurs souvent plus simple.
Merci pour vos réponses, je comprend mieux ces technologies, j'aurai juste besoin d'une dernière précision, est ce que je pourrai travaillé avec linq to entity 2 et mysql ? aurai-je besoin d'un driver spécifique ?
Répondre avec citation
Partager