Récemment, j'ai lu une nouvelle que MariaDB est un remplacement pour MySQL depuis MySQL a des prix hostiles pour la version cluster/entreprise selon Google.
Maintenant, je ne trouve rien de pertinent sur EF pour MariaDB sur Google, donc j'espère que quelqu'un le sait. Est-il correct d'utiliser pilote MySQL pour cela car il est 100% compatible ? Des pensées?
Mise à jour
Je viens de découvrir que RedHat passe également de MySQL à MariaDB pour son système de gestion de base de données par défaut. Il est donc nécessaire pour mon projet actuel de le passer à MariaDB.
J'ai pu utiliser MariaDB 10 avec Entity Framework même si cela a nécessité un peu de travail principalement parce que les outils MySQL sont un peu bogués.
Pour travailler avec MySQL/MariaDB dans Visual Studio 2010/2012 , vous devez installer MySQL pour Visual Studio en utilisant MySQL Installer . J'ai utilisé la version Web car je voulais seulement télécharger les connecteurs et les extensions. Une fois que vous faites cela, vous pouvez ajouter des connexions à MariaDB et créer des modèles EF.
Cependant, cela ne suffit pas pour exécuter votre code. Vous devez d'abord ajouter le connecteur MySQL à l'aide de NuGet.
Malheureusement, MySQL pour Visual Studio ajoute une référence à une ancienne version du fournisseur (mentionnée ici ) et ne peut pas charger la nouvelle version. Pour résoudre ce problème, j'ai ajouté la section suivante dans mon app.config:
<system.data>
<DbProviderFactories>
<remove invariant="MySql.Data.MySqlClient"/>
<add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient"
description=".Net Framework Data Provider for MySQL"
type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.7.4.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
</DbProviderFactories>
</system.data>
Cela remplace l'ancienne référence par une nouvelle. Notez que j'ai utilisé
<remove invariant="MySql.Data.MySqlClient"/>
ne pas
<remove name="MySql Data Provider"/>
dans l'élément remove
.
Actuellement, MySQL pour Visual Studio n'est pas pris en charge dans Visual Studio 2013
MISE À JOUR - 2017
Le connecteur/.NET est essentiellement stagnant, avec les mêmes problèmes qu'il avait en 2013, par exemple pas de vrais appels asynchrones. Les appels "async" sont faux - ils sont exécutés sur des threads séparés, ce qui va à l'encontre du but même de l'utilisation de async
. Cela seul le rend inapproprié pour les applications Web, où l'on veut traiter autant de requêtes que possible en utilisant le nombre minimum de threads/CPU.
Peu importe le support de .NET Core.
C'est pourquoi au cours des dernières années, les gens ont construit leurs propres fournisseurs véritablement asynchrones. Certains des plus populaires sont:
Avec environ 100 000 téléchargements NuGet chacun, des versions fréquentes et une maintenance active.
Ils ne sont pas "officiels", mais valent vraiment la peine d'être essayés