Discussion :

[ctxnop]

Bonjour !
Soyons clair, moi et les bases de données (relationnelle ou non, payantes ou gratuite, MS ou Oracle ou [placer ici votre éditeur favoris]) on est pas copains copains.
Je n'y connais pas grand chose, pour ne pas dire "rien".

Je sais qu'il existe tout pleins de framework pour accéder aux données de manière plus ou moins transparente. Je ne les connais pas tous et je n'ai pas le temps de tous les étudier, aussi j'aimerai votre avis sur ce que je devrais choisir pour répondre le plus possibles à ce que j'aimerais :

- Je voudrais avoir des classes qui mappent une table (table "A" -> classe "A", une colonne = une propriété, ...). Ca normalement ils le font tous (enfin j'espère)

- Je voudrais que ces classes puissent être modifiées pour que je puisse y ajouter des propriétés/méthodes qui n'ont de sens qu'au runtime (donc des choses qui ne sont pas mappées à la base de donnée). Exemple :la table contient 2 champs, donc la classe contient également deux propriétés, et moi je veux pouvoir ajouter une troisième propriété qui calcul un hash des deux premières, hash qui n'est pas stocké en base puisqu'il n'a de sens qu'au runtime du programme.

- Je voudrais pouvoir créer directement les classes plutôt que les tables (je ne suis pas à l'aise avec le SQL). En conséquence, les classes (ou un objet capable de lire ma classe) aurait une méthode qui permettrait de créer la table sur la base de donnée à laquelle je suis connecté.
Exemple :

Code csharp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class User
{
    public string Login{ get; set; }
    public string Password {get; set;}
}
 
//....
DataAccess da = new DataAccess(new SqlConnection("..."));
da.CreateTable(typeof(User));

Dans mon exemple, j'aimerai que mon DataAccess accepte plusieurs types de bases de données, SQL Server est le minimum vital, mais s'il accepte un truc plus généric ca serait bien.
De même qu'il faut pouvoir créer la table via la classe, il faudrait pouvoir détruire la table, vérifier qu'elle existe.
Si ca pouvait également vérifier que la classe n'a pas été modifiée après la création de la table ca serait génial mais bon c'est pas capitale non plus.

- Je ne cherche pas un truc qui gère toute la complexité que les bases de données peuvent offrir.
Mes données seront stockées dans des tables avec clef primaire et si possible clef étrangère. Des champs simples (texte, nombre, date, mais pas de truc poussé genre énum, XML, filestream ou je ne sais quoi).
Une clef étrangère doit donner lieu à une propriété sur une classe qui permet d'obtenir la collection d'objet enfants. Je me moque complètement qu'il y ai gestion ou non des contraintes d'intégrité/de cascade, je ferai avec/ou sans.
Pas de vues, pas de jointure, ou je ne sais quoi. Une gestion très basique des tables me suffit.

Pour faire simple, je veux pouvoir créer des classes, pouvoir enregistrer/charger les données de ces classes dans une base de données sans faire de requête. ex: "MonObjet.Save()"
Et la structure des tables doit être créée à partir des classes (et non l'inverse). (Même si ca veut dire que je dois taper à la main les attributs, les héritages, ou je ne sais quoi d'autre)

Évidemment je ne suis pas contre un outil type designer, mais si il n'y en a pas je vais pas pleurer non plus.

Sachant tout cela, quelle solution choisir ? Je sais qu'il existe pleins de choses genre Linq To Object ou EntityFramework, ou je ne sais quoi d'autre. Mais je ne sais pas ce qu'ils permettent de faire, dans quelle mesure ils répondent à mes besoin, etc.

Contraintes technique : Visual Studio 2008 maximum, Framework 3.5 sp1 maximum.

[cinemania]

alors prérequis minimum si on continue dans cette voie :

- VS2008 je dit OK à condition d'installer le SP1.

Dans l'absolu, je t'aurais proposé d'utiliser ADO.NET Entity Framework, car il correspondait exactement à tes demandes.
Petit souci, tes contraintes techniques.

En effet, sous Visual Studio 2008 SP1 et dotnet 3.5SP1... Entity Framework existe, et fait ce que tu veux.
Cependant sous VS2008 l'outil intégré, l'éditeur de modèle EDM n'est pas en mesure de générer lui même la base depuis le modèle objet.

Il faut que tu comprenne que dès lors que l'on parle de SQL et de données, SQL est roi, par conséquent, on a plutôt tendance à faire le modèle objet après avoir fait le modèle SQL, où on fait soit même son modèle SQL en fonction du modèle objet.
Le problème c'est que même si EF ou NHibernate répondent à tes besoins pour ce qui est de leur coeur de métier... j'entend faire le mapping entre la base et tes objets, et que tu n'ai pas à te demander quoi que ce soit de SQL...
en revanche avec VS2008 aucun des deux à ma connaissances, ne répondent à ton besoin d'un outil intégré capable de générer la base depuis ton modèle objet, et non pas l'inverse.

Il faudrait que je vois si les EDMX 2008 sont "compatibles" avec ceux de 2010, car dans l'absolu, rien n'interdit de fonctionner sous 2008, mais quand il y a besoin de créer la base, d'utiliser la version express de 2010.
Les outils que tu peux trouver, sont généralement des générateurs UML=> base, ou Merise MLD/MPD=>base autant dire... rien puisque tu devrais toi même faire le MLD/MPD en fonction de tes objets.

Cependant je dirais qu'il est possible que l'on te fasse le MLD/MPD
en général la transformation n'est pas très compliquée à faire.
Mais il te faudra alors quelques notions.

D'autres connaissent peut etre des outils qui pourronts te retourner les script SQL nécessaire à défaut de le faire.

Quoi qu'il en soit en ce qui concerne EF ou NHibernate, les deux fonctionnent et ce quelque soit la base, il suffit de fournir la bonne chaîne de configuration dans l'app.config pour EF ou de quelques lignes de code, car en plus de choisir la connexionString il faut indiquer le connecteur à utiliser.
Pour NHibernate je ne me souviens plus trop de ce qu'il est nécessaire à ce niveau là.

Actuellement je ne vois que ces 2 technologies pour répondre à l'ensemble de tes besoins, le problème est qu'il est assez difficile d'utiliser un ORM sans être familier de SQL.
Cependant couplé à l'écriture Linq... EF a des avantages indéniable comme l'intérrogation de la base à la volée en écrivant par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
var customers = from n in ctx.Customers where n.country = "fr" select n;

ce qui obtient une requête qui va te donner une énumération de Customers francais par exemple... (la requete est évaluée quand tu va faire ton foreach ou la convertir en liste ou ce que tu veux...)

[ctxnop]

Merci de te pencher sur ma demande
Je sais quand même faire du SQL, mais je ne suis pas du tout à l'aise avec.
De plus il me semble plus logique de construire le modèle objet avant le modèle SQL puisque ce que je vais manipuler ce n'est pas des enregistrements d'une base de donnée, mais bien des objets.

De plus, une des choses que je n'aime pas avec la construction du modèle SQL c'est qu'il suppose de toujours connaitre la base cible. Puisque les bases n'offrent pas toutes les mêmes capacités (par exemple les schémas qui ne sont pas gérés sur toutes les bases de données) ou ont des différences de syntaxes (comme la syntaxe "[schema].[Table].[Colonne]" de Sql Server).

Enfin, normalement on doit pouvoir considérer le fournisseur de base de donnée comme changeable sans changer le code.

Pour toutes ces raisons je trouve qu'il est plus logique de construire le modèle objet et que ce dernier permette de construire le modèle SQL.

Je suis très très attaché à ce point. Après, l'absence d'un outil graphique pour générer le code en fonction d'un diagramme UML (genre un diagramme de classe) ne me dérange pas. Ça serait un plus, mais dans l'absolut je m'en cogne.

En l'occurrence, pour mon projet actuel, je construit un outil qui se connecte à une base de données, l'utilisateur choisit la base, donc ca peut potentiellement être n'importe quel fournisseur. Une fois connecté l'outil analyse la base et détermine tout un tas de choses. Il doit sauvegarder ces données dans la base à laquelle il est connecté, mais on a aucune garantit que la structure pour cette sauvegarde existe.

Encore une fois je ne cherche pas un framework ultra complet capable de gérer tous les cas métier, toutes les syntaxes SQL et toute les capacités des moteurs SQL modernes. Je cherche surtout un truc simple qui peut construire un modèle SQL simple. Alors bien sur si les "framework ultra complet" sont capables de ca, je vais pas cracher dessus

Moi je vois bien un truc genre des attributs à poser sur une classe et ses propriétés, avec par dessus ca un objet capable de faire de la reflection sur ces attributs.

Je vais toute de même regarder de plus près ce NHibernate et aussi L'Entity Framework. Si j'ai bien compris pour ce dernier, ca fonctionne via un fichier edmx dans Visual Studio ? Et c'est quoi la différence avec Linq To Object (fichiers .dbml), ca m'échappe un peu tout ca moi

[meziantou]

Je vais toute de même regarder de plus près ce NHibernate et aussi L'Entity Framework. Si j'ai bien compris pour ce dernier, ca fonctionne via un fichier edmx dans Visual Studio ? Et c'est quoi la différence avec Linq To Object (fichiers .dbml), ca m'échappe un peu tout ca moi

EF utilise Linq to Entities pour créer les requêtes. L'intérêt de EF est de pouvoir séparer le modèle relationnel du modèle objet. Par contre dans la version 1 il n'y a pas de lazy loading.

les fichier dbml c'est pour Linq to SQL. Technologies existant avant EF. Elle est actuellement délaissée par MS.

Linq to Object n'est pas fait pour EF ou Linq to SQL mais bien pour les objets comme son nom l'indique. Un petit exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
List<int> list = new List<int>{1,2,3};
var a = from i in list
           where i > 2
           select i;

[ctxnop]

Je dois avouer ne pas avoir compris grand chose de ce que tu viens de dire
"EF utilise Linq To Entities", ok, mais c'est quoi ? Qu'est-ce que ca offre par rapport à du Linq "normal".
Je veux dire, je connais un peu Linq, je sais qu'il permet d'offrir une syntaxe assez proche du SQL pour requêter des objets énumérables tels que la List<int> de ton exemple.
Le nom (Linq To Entities) laisse penser penser qu'il permet de faire la même chose mais sur des "entité". Sauf que ca ne dit pas ce qui est considéré comme entité, a quoi ca sert, dans quel cas on doit passer par la, etc...
Même remarque sur le Linq To Object.
D'ailleurs ton exemple c'est faisable directement sans passer par un fichier DBML (fichier utilisé quand on ajoute un nouvel élément de type Linq To Object).
Dans tous les cas, si la techno est délaissée il serait judicieux de se tourner vers une autre. Pour mon projet du jour ce n'est pas grave si la techo n'existe plus dans 2/3 ans, mais quitte a apprendre a maitriser un framework, autant que ce soit un qui va me resservir pendant longtemps.

J'ai très rapidement jetter un oeil à EF sous mon Visual Studio 2010 ultimate hier, vraiment très rapidement. Le peu que j'en ai vu c'est exactement ce que je cherche. Enfin, je n'ai pas eu le temps de voir comment, par code, on peu créer la structure sql via les classes, mais dans le designer il y a une fonction qui permet de le faire donc ca doit être faisable par code aussi.

Et la de suite je suis en train de regarder NHibernate, lui aussi semble correspondre au besoin. J'ai déjà vu comment créer les tables a partir des classes, ca se fait en 3 lignes de code.
Il semble un peu plus complexe à utiliser. Pas besoin d'attributs ou d'héritage pour faire entrer une classe dans le modèle, cependant il faut se farcir un XML de mappage. J'aime assez l'idée. Par contre, dans tous les exemples que j'ai vu il faut également se taper des requêtes, et la je ne suis plus d'accord. Si je veux un framework de ce genre c'est justement pour ne plus faire de requêtes. D'autant plus qu'il faut le faire dans une syntaxe "HQL" ce qui implique d'apprendre une syntaxe supplémentaire alors que je cherche justement a me débarrasser de tout langage de requêtage.

Bon j'en suis qu'au début de mes recherches alors je dis peut être n'importe quoi, il y a peut être d'autres méthodes et je ne suis tout simplement pas encore tombé dessus. Mais du coup, pour le moment je m'orienterai plutot vers EF a condition que je trouve comment créer les tables a partir des classes.

[cinemania]

oui Linq to Object, est en fait une extensions des écritures Linq, et des fournisseurs Linq à tout le code non SQL ou XML.

quand tu manipule des objets mémoires, genre des int comme montré précédemment, tu fait du Linq To Object car tu utilise les extensions Linq.
si maintenant tu manipule des entités générées par EF avec un contexte, alors tu fait du Linq to Entities.

Linq To Entities a un gros défaut toutefois... bien que tout soit fait à l'exécution, et qu'il manipule de vraies requêtes en bases, il nécessite des "providers" de code SQL capable de convertir tes requêtes de code en SQL.
C'est natif pour SQL Server.
Le connecteur MySQL.NET possède le provider pour Entity Framework également, où il existe l'alternative devart, mais bon vu que le composant original est gratuit...
Pour Oracle à part le composant devart, il n'y a pas de vrai connecteur dotnet qui fournit les providers EF pour l'instant. Oracle s'est toutefois décidé à en développer un... (en même temps, ils n'ont plus trop le choix)
Pour Postgres il en existe un si mes souvenirs sont bons, et tu peux toujours aussi avoir l'alternative devart.

pour les autres il faut chercher. Devart fourni une lib de connecteur impressionnante, mais ils sont tous payants donc...

en meme temps attention... tu ne peux utiliser EF ou NHibernate que pour un domaine de base que tu connais, je veux dire que les bases que tu explore, tu dois les explorer autrement... les ORM ne sont pas conçut pour cela.
Ils sont conçut pour gérer ton modèle de données, et les données que tu va collecter.

[ctxnop]

Merci pour cet éclaircissement.

en meme temps attention... tu ne peux utiliser EF ou NHibernate que pour un domaine de base que tu connais, je veux dire que les bases que tu explore, tu dois les explorer autrement... les ORM ne sont pas conçut pour cela.
Ils sont conçut pour gérer ton modèle de données, et les données que tu va collecter.

Je n'ai pas compris ce que tu voulais dire
Un domaine de base que je connais ? C'est à dire ?
Tu parle peut être de ce que j'ai dit sur mon projet actuel, l'analyse de la base à laquelle je me connecte. Je ne pourrais pas utiliser EF pour analyser la base dans la mesure où je ne connais pas son contenu avant d'y être connecté. C'est ca ?
Si c'est ca c'est pas grave du tout. Pour cette analyse je le ferais via requête. Ce projet n'est qu'un exemple de pourquoi je cherche un framework type EF. J'ai été confronté à devoir enregistrer mes objets en base de très nombreuses fois et j'en ai plus que marre de passer 3 semaines à créer mes tables et mes requêtes alors que je créer le modèle objet en 2h.
Dans 80% du temps je n'ai pas besoin de tout ce que peut faire une base de données (trigger, procédure, vues, ...), j'ai juste besoin d'un stockage des données, hébergé sur serveur (sinon je ferai de la sérialisation je pense).
J'ai souvent songé à écrire moi même un moteur pour faire de l'abstraction sur ca. Mais depuis j'ai appris que ca existait déjà et donc je n'ai pas envie de réinventer la roue, surtout que les gens qui ont créé ces framework sont très certainement plus compétent que moi sur les bases de données (en même temps c'est pas dur).
Aujourd'hui je suis confronté une fois de plus au problème, je me dit qu'il est surement temps de m'intéresser à ces framework, d'apprendre à les utiliser et ainsi rajouter une corde à mon arc.

[ctxnop]

Bon voilà, j'ai rapidement testé les deux (EF et NHibernate).
Le résultat est que :

- EF fournit un designer dans visual studio ce qui est fort pratique, seulement le EF dans mon Visual Studio 2008 ne me permet pas de créer les tables via les classes, en conséquence je l'abandonne. Du moins au boulot, je le testerai un peu plus pour mes projets persos où je peux utiliser mon VS 2010. Je ne sais pas si je l'adopterai à terme ou non.

- NHibernate est un peu plus complexe à mettre en œuvre je trouve. La documentation n'est pas toujours très claire notamment sur cette histoire de lazy loading. Le mapping doit être fait à la main via un fichier XML ce qui est un chouilla long, mais bon c'est pas trop dur non plus. On peut utiliser un ClassDiagram (.cd) pour concevoir les objets, ou les écrire à la main. La mapping étant fait via un fichier XML il n'y a pas d'attributs à poser ni de règles particulière à suivre.

En conséquence je m'oriente vers NHibernate. Mes testes rapides me posent encore quelques problèmes, par exemple lors de la création des tables le schéma ( ex "dbo") doit exister, il ne le crée pas s'il n'existe pas.
De même, toujours pendant cette création, je n'ai rien trouvé pour vérifier si la structure existe déjà et donc ne pas la recréer (auquel cas il détruit toutes les données). Du coup je suis toujours obligé pour le moment de faire du SQL pour faire ces vérifications.

Il faut que je m'habitue à tout ces concepts de ISessionFactory, ISession, etc, mais dans l'ensemble ca à l'air de répondre à mes besoins sans grande complexité.

Merci à vous deux pour m'avoir aider dans ce choix