Linq et MySql (suite)

Dans une précédente note, je parlais du provider DBLinq: Pour le tester, j'avais commencé à réécrire mes providers MySql (Membership, Role, Profile et Personnalization). Mais le framework ne permettait pas d'aller très loin, trop de buggs.

Après quelques échanges, l'équipe confirme être assez réactive sur les buggs remontés et les features. Le portage continue donc au rythme des corrections. De fait, je suis beta testeur pour ce groupe de travail. L'équipe compte déjà onze personnes.

Les providers seront mis sur CodePlex également dès qu'ils seront aboutis, ou avant si cela intéresse d'autres développeurs.

Ok, mais quel intérêt?

• Pour le portage de CodeFx.MySqlProviders: bien que MySql AB fournisse les providers officiels pour MySql, à ce jour, seuls Membership et Role sont disponibles, Profile et personnalization (Web Part) ne sont pas dans le scope. De plus, la mise en ligne des providers est assez longue. Donc, il peut être interessant de fournir ce code afin de pouvoir rapidement travailler avec le framework 3.5.
  
• Pour le provider MySql pour LinqToSql, toujours dans cette note, je mentionne que MySql va avoir son propre provider pour LinqToEntities dans les prochains mois. Il sera alors évidement plus intéressant de passer sur LinqToEntities.
  Cependant, il semble avoir une raison d'être pour une utilisation avec le projet Mono:
  A lire cette note postée sur le group google DBLinq:
  

> What are the benefits of DbLinq provider, compared to ADO.NET EF?

I hope to use DbLinq with MONO to create application which runs in Windows, Linux and Mac.
Linq has a much less code to implement. MONO C# 3 compiler is almost complete. MONO SVN includes 3.5 System.Core assembly. MONO Olive includes Linq assemblies, all in pre-alpha through.
Entity Framework seems to have a lot of code. Porting this to Linux/Mac is not attempted and may be never tried.

Pistes pour migrer sous Visual Studio 2008 - Part I

Au-dela des gains de productivités annoncés, des améliorations du langage C#3 qui sont traités dans différents blogs, l'arrivée de VS2008 avec le framework 3.5 apporte des pistes intéressantes dans certains contextes projets:


Part I : Application centrée données dans un modèle Off-shore

Délocaliser des applications centrées sur les données peut poser des problèmes simples de compréhension entraînant une perte de productivité:
Dans le cas d'un développement avec le design pattern Active Record par exemple, le développeur manipule des objets avec une terminologie qu'il ne maitrise pas, voir une langue qu'il ne connait pas, dès lors qu'il travaille avec des bases de données existantes.

Le retour d'expérience montre que ce point n'est pas à sous-estimer, même s'il n'apparait pas dans les publications sur l'offshore (lire le livre blanc Publication du Cigref sur le retour d'experience du modèle OffShore par exemple), sur l'appropriation du code et les anomalies fonctionnelles.

Sans avoir à passer par un framework externe type NHibernate (lire le débat NHibernate vs Linq sur le blog de Maximilian Beller) pour mettre une couche d'abstraction entre la base de données et le code, LinqToSql et surtout Entity Framework, en bon framework ORM, permettent un mapping déclaratif entre l'applicatif (avec des classes et des propriétés en anglais) et le schéma de la base (avec des noms des tables/vues, colonnes en français par exemple).

Sans parler ici de l'apport d'un ORM ni de sa limitation (pas de modélisation UML, approche plutot data centric malgré la souplesse apportée par le mapping des vues et des procédures stockées), il permet aux développeurs de travailler avec une terminologie plus fonctionnelle que technique et en anglais, et tout ça natif et standard .Net. Le cout d'apprentissage peu élevé (grâce au modelleur graphique) est surtout lié au langage de requêtage linq.

Comme nous le verrons également dans la seconde partie de la note, l'idée est bien de bénéficier des apports d'un ORM intégré à l'IDE tout en restant centré sur les données.

LinqToSql apporte moins d'abstraction qu'Entity Framework, comme je l'ai déjà souligné ici, puisqu'il est spécialisé SQLServer.

Pour avoir plus d'info sur sa mise en oeuvre.

Pour les applications utilisant déjà NHybernate, des providers voient le jour pour bénéficier de linq, plus précisement de la syntaxe de requêtage objet.

Linq et MySql

Peut-on utiliser MySql avec Linq aujourd'hui?

Le framework Linq (sur msdn ou wikipedia), fait parti de la release de .Net Framework 3.5 (novembre 2007), mais pouvait déjà être utilisé en tant que librairie dans ses versions beta.

Différents providers natifs pour Linq sont disponibles aujourd'hui dans des versions assez finalisées, mais les deux qui nous interessent pour nos bases MySql sont LinqToSql et Entity Framework.

Entity Framework
Entity Framework est destiné à être ouvert aux autres moteurs de base de données comme l'annonce Microsoft dans son communiqué de presse ou sur le blog d'ADONet:

Providers Targeting Publicly Available Versions Within Three Months of RTM

MySql devrait donc avoir ses propres providers, mais fournis par des tiers:

• Core Lab fourni déjà une implémentation que l'on peut tester dans une version trial, mais personnellement je n'ai pas réussi à créer d'Entity Data Model avec.


• MySQL AB, mais pas de date ni de version beta pour l'instant.

La version beta 3 de l'Entity Framework est déjà bien finalisée mais elle n'est pas au niveau de LinqToSql qui elle est déjà en version RTM. Il manque entre autre un support drag & drop pour la modélisation graphique, des buggs fix (modification d'un modèle, plusieurs schémas en base de données,...).

La version RTM doit arriver avec Visual Studio 2008.

Difficile donc de tester MySql sur ce framework aujourd'hui.

LinqToSql
Ce provider a pour cible les bases Sql Server uniquement. Entity Framework est donc la cible pour une utilisation avec des bases MySql.

Pour attendre des versions RTM des providers, on peut alors se tourner vers des solutions alternatives telles que le projet DB_Linq qui aujourd'hui gère MySql, Oracle et PostGreSql en s'appuyant sur LinqToSql.
Ce projet Open Source, qui a débuté en 2007, est jeune mais interessant pour ceux qui veulent faire des premiers tests avec MySql.
Il n'y a donc pas de support graphique pour les modèles, à l'instar de LinqToSql. Le DataContext (MContext ici) doit donc être généré via une adaptation de SQLMetal pour MySql, comme aux premières heures de Linq. SQLMetal est un projet en code DOM, permettant de générer du code source en s'appuyant sur des schémas de base de données.

Pour le tester, j'ai fait une adaptation de mon projet CodeFx.MySqlProviders. Bien que l'équipe du projet soit très réactive, la ToDo list du projet est encore longue (je cite quelques points que j'ai rencontré dans mes tests, mais ce n'est pas exhaustif):

• Les longblob ne sont pas encore implémentés. Du coup, Les providers Profile,
  Personnalization ne peuvent pas encore être implémentés.


• Le MContext n'implémente pas IDisposable, ce qui enlève le pattern using. Il suffit cependant de l'implémenter dans une classe partielle.


• SqlMethods.Like plante. Pour utiliser des clauses Like on pourrait utiliser la méthode ExecuteQuery mais elle n'est pas encore implémentée ...
  Elle n'est de toute façon pas une solution, le but d'un ORM n'est pas d'avoir du code Sql qui traine dans la couche métier. De plus, ExecuteQuery ne supportent pas les types anonymes (cf. le billet de Rick Strahl), ce qui peut poser des problèmes sauf à utiliser des vues.


• D'autres limitations sont plus imputables à Linq (La pagination par exemple car aujourdhui ne sont supportés que des Take(x) (Limit 0,x), First, Last, ...
  ) ou MySql selon les versions (requêtes imbriquées pas avant MySQL 4.1, vues pas avant MySQL 5).
  

De toute façon, il faut se poser la question de la pérénité d'une telle approche.

Pour aller un peu plus loin sur les providers tiers linq.

ps: pour tracer le code sql produit par le framework linqtosql, lire le billet de Kris Vandermotten

En conclusion, il est encore un peu tôt pour faire des tests MySql avec linq même si l'on nous promet une visibilité pour le premier semestre 2008.