Actuellement je travaille sur un gros projet qui est utilisé avec PostgreSQL. Malheureusement, le provider de cette base de données (Npgsql) ne prends pas en charge une intégration totale avec les possibilités offertes par les interfaces de Visual Studio. Il nous est donc impossible de générer l’Edmx via Visual Studio. Bien sûr, il existe des providers payants qui permettent de le faire (je pense bien sûr à Devart), mais ce n’est pas le but de l’article.


C’est pour cela qu’il existe un fabuleux outil qui s’appelle “EdmGen2” disponible sur le MSDN Code Gallery. L'outil peut être utilisé comme un remplacement pour l'outil EdmGen qui est fourni avec le Framework. Net 3.5 SP1. EdmGen ne peut que lire et écrire les fichiers CSDL, SSDL et MSL. Par contre, EdmGen2 peut lire et écrire le format de fichier EDMX utilisée par les outils de conception de Visual Studio.

Note : avant de générer le fichier, il faut s’assurer que le provider est installé dans le GAC.

Donc, pour générer le fichier Edmx de notre base PostgreSQL, nous allons utiliser l’option modelgen d’edmgen2.exe, où il faut respecter la syntaxe suivante :

edmgen2.exe /modelgen "Port=5432;Encoding=WIN1252;Server=IBM-SERVER;
                       Database=Northwind;UserId=postgres;Password=1234" Npgsql Northwind

Une fois la commande effectuée, vous aurez le fichier Northwind.edmx de crée, il vous suffira de l’ajouter à votre projet et il sera utilisable directement.

Note : n’oubliez pas votre fichier App.config, il ne sera pas crée automatiquement, comme avec l’assistant de Visual Studio ;-).

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
  </configSections>
  <connectionStrings>
    <add name="NorthwindEntities" connectionString=
        "metadata=res://*/Northwind.csdl|res://*/Northwind.ssdl|res://*/Northwind.msl;
        provider=Npgsql;provider connection string=&quot;
        Port=5432;Encoding=WIN1252;Server=IBM-SERVER;
        Database=Northwind;UserId=postgres;Password=1234&quot;"
      providerName="System.Data.EntityClient" />
  </connectionStrings>
</configuration>

A bientôt :)

Avec Linq To Sql, on a l’habitude, en phase de débogage, d’utiliser le code suivant :

AdventureWorksData context = new AdventureWorksData();
context.Log = Console.Out;

Le log nous permet de voir toutes les requêtes qui sont générées par Linq To Sql. Donc, avec le code suivant, nous aurons en console la requête générée :

AdventureWorksData context = new AdventureWorksData();
context.Log = Console.Out;

var query = from p in context.Product
            where p.Color.Equals("Black")
            select p;

foreach (var q in query)
{
    Console.WriteLine(q.ProductID);
}

Console.Read();

// Requête générée envoyée dans la console
SELECT [t0].[ProductID], [t0].[Name], [t0].[ProductNumber], 
       [t0].[MakeFlag], [t0].[FinishedGoodsFlag], [t0].[Color],
       [t0].[SafetyStockLevel], [t0].[ReorderPoint],
       [t0].[StandardCost], [t0].[ListPrice], [t0].[Size], 
       [t0].[SizeUnitMeasureCode], [t0].[WeightUnitMeasureCode],
       [t0].[Weight], [t0].[DaysToManufacture], [t0].[ProductLine],
       [t0].[Class], [t0].[Style], [t0].[ProductSubcategoryID], 
       [t0].[ProductModelID], [t0].[SellStartDate], [t0].[SellEndDate],
       [t0].[DiscontinuedDate], [t0].[rowguid], [t0].[ModifiedDate]
FROM [Production].[Product] AS [t0]
WHERE [t0].[Color] = @p0

Avec EF, cela ne se met plus en place tout à fait de la même manière. Nous pouvons faire le log avec ObjectQuery.ToTraceString(). Voici l’exemple ci-dessus remodelé pour EF et ToTraceString() :

AdventureWorksEntities context = new AdventureWorksEntities();

var query = from p in context.Product
            where p.Color.Equals("Black")
            select p;

// Affiche la requête
Console.WriteLine(context.Product.ToTraceString());

foreach (var q in query)
{
    Console.WriteLine(q.ProductID);
}

Console.Read();

// Requête générée
SELECT
[Extent1].[ProductID] AS [ProductID],
[Extent1].[Name] AS [Name],
[Extent1].[ProductNumber] AS [ProductNumber],
[Extent1].[MakeFlag] AS [MakeFlag],
[Extent1].[FinishedGoodsFlag] AS [FinishedGoodsFlag],
[Extent1].[Color] AS [Color],
[Extent1].[SafetyStockLevel] AS [SafetyStockLevel],
[Extent1].[ReorderPoint] AS [ReorderPoint],
[Extent1].[StandardCost] AS [StandardCost],
[Extent1].[ListPrice] AS [ListPrice],
[Extent1].[Size] AS [Size],
[Extent1].[SizeUnitMeasureCode] AS [SizeUnitMeasureCode],
[Extent1].[WeightUnitMeasureCode] AS [WeightUnitMeasureCode],
[Extent1].[Weight] AS [Weight],
[Extent1].[DaysToManufacture] AS [DaysToManufacture],
[Extent1].[ProductLine] AS [ProductLine],
[Extent1].[Class] AS [Class],
[Extent1].[Style] AS [Style],
[Extent1].[ProductSubcategoryID] AS [ProductSubcategoryID],
[Extent1].[ProductModelID] AS [ProductModelID],
[Extent1].[SellStartDate] AS [SellStartDate],
[Extent1].[SellEndDate] AS [SellEndDate],
[Extent1].[DiscontinuedDate] AS [DiscontinuedDate],
[Extent1].[rowguid] AS [rowguid],
[Extent1].[ModifiedDate] AS [ModifiedDate]
FROM [Production].[Product] AS [Extent1]

On remarquera qu’à la différence avec Linq to Sql, il faut définir exactement quelle requête nous voulons voir.

Bien sûr, si vous utilisez SQL Server, vous pouvez aussi utiliser SQL Profiler, pour avoir un monitoring plus “poussé”. Pour les autres bases de données, il existe aussi des outils équivalents.