Bonsoir !

Beaucoup utilise directement le MySQL Connector/NET mais d'autres utilise des ORM (object-relational mapping). Justement, mon problème c'est l'utilisation d'un ORM, j'ai utilisé DbEntry et Castle ActiveRecord mais aucun n'a su m'aidé. Ils ont plutôt pour but d'être utiliser simplement, recherche de données, création, suppression et modification (même si ActiveRecord est plus complet pour les jointures). Malheureusement, dans mon cas, je souhaite mettre en cache les données pour optimiser les performances de mon application. Aucun des deux ORM utilisés ne proposent des solutions de cache, ce qui est dommage. Donc je compte réutilisé le MySQL Connector/NET pour avoir un maximum de souplesse, au détriment de la rapidité de développement des entités. C'est pour cela que je souhaite connaitre votre point de vue, écouter vos conseils et critiques.

Dites moi de suite si j'suis à côté de la plaque... Mais t'as déjà tenté ADO.NET Entity Framework 4? Normalement, il est interfaçable avec n'importe quel connecteur de données; les fonctionnalités disponibles dans EF4 dépendant directement du connecteur utilisé (Par exemple, le mode "Identity" ou "Computed" pour les clés primaire d'entités ne sont pas disponibles avec le connecteur Microsoft SQL Server CE 3.5)

Niveau fonctionnalités théoriques, EF4 peut gérer :
-Un cache de données => Une instance du contexte d'entité retient en mémoire toutes les entités chargées...Si une entité A a déjà été chargée et qu'une entité B ayant besoin de A va être chargée, entité A ne sera pas rechargée à partir de la base de données (sauf si explicitement demandé)
-Le chargement en différé => Si une entité A, disposant d'une relation vers une entité B, va être chargée, l'entité B ne sera pas chargée en même temps (sauf si explicitement demandé)...Cette entité B ne sera chargée que si tu tente d'accéder à la relation en passant par la propriété de navigation adaptée, générée automatiquement par EF4 lors du designing.
-Les relations (encore heureux XD) => Chaque table (ou presque) représentera une classe. Les relations n-n sont automatiquement gérées et apparaissent dans le code sous forme de collection d'entité (on ne touche jamais à la table permettant de faire la relation n-n donc...Ca limite les erreurs).
-L'héritage d'entité => Tu peux facilement suivre un concept d'héritage objet qui sera traduit automatiquement par EF4 sous forme de 2 tables : La première table contenant la classe de base, la seconde table contenant les champs de la classe fille + une colonne à la fois clé primaire et étrangère (non visible dans le modèle ou dans le code) qui pointe vers la clé primaire correspondante à la classe mère en cours.
-Couplé avec Linq-To-Entities, il est très facile de faire des requêtes complexes et/ou puissantes d'accès aux données (jointures externe, interne, filtrage, pagination, tri, classification...)
-Surement d'autres trucs que je ne connais pas ou que j'ai oublié de citer ^^.

Après, comme je l'ai dis, je te raconte tout ça parce que je ne m'en suis servi qu'avec des connecteurs vers SQL Server (et donc des bases de données SQL Server)...Si le connecteur MySQL pour .NET ne propose pas les implémentations nécessaire à certaines fonctionnalités d'EF4/Linq-To-Entities, possible que ça ne soit pas aussi terrible que ça .

EF4 ça tronçonne du castor

A priori Entity Framework devrait fonctionner bien gentiment avec MySQL Connector/NET

J'ai regardé un petit peu la MSDN sur Entity Framework mais je trouve qu'elle n'est pas très bien faite pour un débutant :/

Citation : Blackrush

J'ai regardé un petit peu la MSDN sur Entity Framework mais je trouve qu'elle n'est pas très bien faite pour un débutant :/

Hé....Ho...
On parle de technologie Microsoft...Là où la complexité devient plus simple grâce au clic-clic XD.

Plus sérieusement, EF4 se prend très facilement en main => T'ouvres Visual Studio, tu ouvres ton projet, tu fais "Ajouter un nouvel élément", tu sélectionne le modèle d'entité ADO.NET (me rappelle plus du nom exact) et tu laisses Visual Studio faire le reste à ta place pour arriver sur un designer d'entité totalement graphique ^^. C'est du clic-clic du début jusqu'à la fin.

Citation : Orwell

EF4 ça tronçonne du castor

Ah?!? Je connaissais pas cette expression . Ca viendra compléter les "Ca envoit du paté" et cie XD

Faut juste faire gaffe avec le designer d'Entity Framework, il a tendance à faire des conneries quand on renomme les propriétés (genre ne les renommer qu'à moitié dans le XML derrière) :/

Citation : Nisnor

Citation : Orwell

EF4 ça tronçonne du castor

Ah?!? Je connaissais pas cette expression . Ca viendra compléter les "Ca envoit du paté" et cie XD

C'est une expression propre à la génération Prologin 2005. Comme quoi Prologin, ça vous marque à vie.

Citation : Aethec

Faut juste faire gaffe avec le designer d'Entity Framework, il a tendance à faire des conneries quand on renomme les propriétés (genre ne les renommer qu'à moitié dans le XML derrière) :/

C'est vrai que j'ai parfois eu des trucs bizarres... Rien d'insurmontable heureusement. Sinon, pour ceux qui n'aiment pas le clic-clic dont parle Nisnor il y a aussi l'approche Code-First maintenant.