Indépendance de la base de donnée avec ADO.NET ou LINQ ?

Bonjour,

Dans le cadre de mon projet, je dois créer une interface graphique WPF qui va chercher les données dans une base de donnée PostgreSQL. Je suis débutant en C# et je souhaite rendre mon projet réutilisable. C'est à dire qu'à l'avenir si l'on doit changer le type de base de donnée, que le programme n'en soit pas affecté.

J'ai entendu parler des différentes technologies ADO.NET et LINQ. Pouvez-vous me conseiller un peu plus sur ce qui serait meilleur de faire.

Merci d'avance. :ccool:

Narglix

Salut,

voilà une saine initiative :)

ADO.Net permet en effet de largement s'abstraire de la base utilisée. Tu trouveras pas mal d'info dans cet inévitable tutoriel : http://johannblais.developpez.com/tu...acces-donnees/

Tu ne pourras par contre t'abstraire complètement de la base, car les différents SGBD ont des syntaxes qui peuvent différer.

Je t'invite aussi à modifier le titre de ton topic, parce qu'il est pas suuuuuper précis. :)

Merci pour le lien ;)

Par contre, ils ne font jamais référence dans l'article à ADO.NET et LINQ. Est-ce que cela est intégré directement à ADO ?

Quand est-ce qu'il est utile d'utiliser LINQ par exemple ? ou pourrais je m'en passer ?

Je vais encore faire quelques recherches de mon côté mais si quelqu'un a des explications je suis preneur :ccool:

Merci encore !

Narglix

ado.net est ce qui sert à se connecter aux bases de données en .net
donc en théorie tout accès avec le framework à une base de données passe par ado.net
linq to sql ou entity framework passent aussi par ado.net

pour des bases de données non prises en charge nativement par le framework il faut ajouter une dll en référence qui en théorie hérite des classes de bases du framework

en accès standard, pour avoir un code réutilisable il faut par exemple avoir des méthodes as system.data.common.DdDataReader par exemple
comme ca dans cette méthode tu instancies soit un sqldatareader (sql server), soit un oledbdatareader (access), soit autre chose

comme dit précédement les connecteurs tiers (comme mysql connector) héritent en général des classes qui sont dans system.Data.common


linq sert juste à changer le mode d'écriture, en écrivant des requete sql en .net en gros
donc si tu veux changer de base avec du linq to sql, il faut que le type de sgbdr accepte linq to sql, et refaire l'import des tables, le code reste le même partout


le mieux c'est que tu fasses des essais tout de suite avec 2 sgbdr pour voir si la solution que tu choisis permet le changement de sgbdr

Merci pour ta réponse détaillée :ccool: j'ai fait des recherches et j'ai lu un article sur entity framework qui permettrait de ne plus avoir besoin de requête SQL donc dans un sens vu que le grand problème d'avoir différents SGBDs c'est la syntaxe des différentes requêtes SQL.

Le mieux si j'ai bien compris pour que le code soit réutilisable est d'employer l'entity framework logiquement ou je me trompe ?

linq to sql ou entity framework permettent de faire abstraction du code sql, une classe intermédiaire s'en occupant

par contre linq to sql doit etre supporté par pal de sgbdr, alors que pour entity framework ca doit etre plus limité, en effet il faut une classe intermédiaire plus complexe

entity framework apportant plus de souplesse dans l'utilisation

Bonjour,

Pol 63 a tout a fait raison, j'ajouterais que Linq to sql n'est supporté que par sql server du coup Microsoft a abandonné son développement pour Entity, du coup tu es lié a Sql Server et dans ton cas inutilisable (PostgreSQL).

L'avantage d'utilisé un ORM tel que Entitiy c'est qu'il te permet de faire un "abstraction" de ta bdd et de te concentré sur le modèle de ton application. Pour cela il te fournira des Objet en relation avec ton modèle de bdd en te "cachant" la manière dont il les a obtenu (la connexion a la bdd, les requêtes ....). Par contre ce sont des outils qu'il faut maitrisé car il doivent être configuré de façon optimal.

Mon conseil perso, si tu n'es pas tres expérimentée, utilise la bonne vieille méthode de requête a la main ou en utilisant des proc stock. Modèle ton application en ntiers. Apprend a utilisé le polymorphisme dans les couches les plus hautes en utilisant par exemple des interface, tu as un excellent tutorial de Didier Danse sur ce site http://ditch.developpez.com/dotnet/factories/ .


Bon codage ^^

Citation:

---

Envoyé par Pol63

par contre linq to sql doit etre supporté par pal de sgbdr, alors que pour entity framework ca doit etre plus limité, en effet il faut une classe intermédiaire plus complexe

---

Euh, c'est le contraire :aie:
Linq to SQL n'est supporté que pour SQL Server (et SQL Server CE il me semble). Entity Framework est plus ouvert et permet de supporter n'importe quel SGBD, à condition qu'un provider soit implémenté. Pas sûr que ce soit le cas pour PostgreSQL...

Sinon comme ORM il y a aussi NHibernate. La prochaine version (encore en beta) supporte également Linq, mais je crois que c'est pas encore complètement au point

Je pensais qu'Entity Framework était quelque chose de nouveau apparu avec Visual Studio 2008 donc forcément mis à disposition pour les développeurs pour faciliter ces interactions avec les SGBD.

Donc étant débutant, j'oublie Entity framework. Je vais suivre le tutorial. Merci encore pour le lien.

Citation:

---

Envoyé par tomlev

Euh, c'est le contraire :aie:
Linq to SQL n'est supporté que pour SQL Server (et SQL Server CE il me semble). Entity Framework est plus ouvert et permet de supporter n'importe quel SGBD, à condition qu'un provider soit implémenté.

---

en fait linq to sql étant apparu avant et ayant moins de surcouche (enfin je pense), ca me semblait logique qu'il soit supporté par plus de sgbdr

Oui c'est le cas, ce type d'outil n'est pas nouveau, Entity est ce que l'on appel un ORM.
Il sert effectivement a facilite la tache du développeur mais pour un débutant que l'effet risque d'être inverse car ca demande plus de temps à appréhender.

Y a un débat qui traite sur les ORM :

http://www.developpez.net/forums/d76...-performances/

J'ai trouvé la dll suivante pour permettre d'utiliser un provider pour Postgre SQL :

http://www.connectionstrings.com/Providers/npgsql

Maintenant il me reste plus qu'à chercher comment ajouter ce provider à Visual Studio.

clic droit sur le projet / ajouter une référence

Merci beaucoup j'étais déjà entrain de partir sur autre chose, genre Global Assembly Cache lol :mouarf:

Citation:

---

Envoyé par tomlev

Sinon comme ORM il y a aussi NHibernate. La prochaine version (encore en beta) supporte également Linq, mais je crois que c'est pas encore complètement au point

---

Nan, NHibernate fait déja du LINQ depuis l'an dernier, avec le provider linq sorti peu après la 2.1 de NHibernate.

Sinon, pour Postgres, sorti de NHibernate, tu as aussi Subsonic en Open-source, et LLBLGEN en payant qui font bien leur boulot.

Pour le débat mentionné quelques lignes dessus, personnellement, je ne m'aventurerais pas à critiquer le fond du débat, mais au final, un ORM ne demande pas plus de temps à maitriser que ce qu'on pense, à condition d'avoir déjà une bonne maitrise de la théorie des SGBD (pour éviter les select n+1 et autres joyeusetés destructrices de performances...).

C'est sur que tous les DBA du monde vont lever le bouclier à l'introduction d'un ORM, le but du jeu restant de bien balancer les requêtes simples faites avec l'ORM, et les grosses requêtes compliquées, qu'on passe en procédure stockée pour des questions de perf. ;)