#Zied

Nous pouvons debugger notre code au sein d’un service WCF de la même manière que tout autre code .NET, en définissant des points d’arrêts au niveau du code que  nous voulons débugger et si nous utilisons le serveur web IIS nous devons alors nous attacher au processus de ce dernier. Mais il arrive que notre code s’exécute bien et ne lève aucune exception alors que côté client nous récupérons une erreur qui ressemble à ça :

“The remote server returned an error: NotFound” pas très explicite comme erreur surtout lorsque vous savez que le code du service WCF a bien été atteint et qu’il s’est bien exécuté sans problème. Le problème s’est donc passé au sein de WCF après l’exécution de votre code du service. Pour avoir une erreur plus explicite et comprendre ce qui se passe réellement il suffit d’activer le tracing côté WCF en ajoutant cette entrée dans le web.config

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          <add name="WCFListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\wcflog\WCFTraces.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Après un nouvel appel de votre service, rendez vous au répertoire c:\wcflog et double cliquez sur le fichier WCFTraces.svclog, vous allez pouvoir découvrir la vraie exception

D’un coup, tout devient plus clair, dans mon cas j’ai un cycle dans mes classes.

Dans la première partie de cet article nous avons vu qu’Entity Framework 4 génère des Proxys qui héritent de nos classes POCO afin de leur ajouter des facultés de “Change Tracking” et de “Lazy loading” et nous renvoyait ces proxys. Nous avons vu que ces proxys posaient un problème lorsque nous avons voulu les sérialiser pour les exposer via un service WCF et nous avons contourné ce problème en mappant ce proxy en notre type original pendant la phase de sérialisation, de cette manière nous travaillons avec des POCO en bénéficiant de tous les apports d’Entity Framework comme le “Tracking” ou encore le “Lazy Loading” qui ne sont sincèrement pas un luxe.

Cette idée est néanmoins un “Work around” et j’ai tout de suite vu ces limites lorsque j’ai essayé de renvoyer un objet avec des entités liées => retour à la case départ problème de dé sérialisation … Il existe un autre moyen de travailler avec Entity Framework et des POCO que nous allons illustrer dans cet article.

En effet, nous pouvons choisir de dire au context que je ne veux pas qu’il génère des proxys de cette manière

context.ContextOptions.ProxyCreationEnabled = false;

Mais dans ce cas il faut assumer ces responsabilités :) Entity Framework ne fait plus de Tracking de changement sur les entités ni de Lazy Loading, les entités doivent donc accomplir ces fonctionnalités toutes seules, et c’est qui qui s’y colle? Bien évidemment ce n’est pas nous :). Je ne sais pas si vous vous en souvenez mais nous avons parlé dans cet article d’un Template T4 fournit par l’équipe ADO.NET qui génère les entités POCO à partir du modèle edmx, ce template nous génère avec nos POCO la partie qui s’occupe du Tracking de changements et les entités deviennent alors des STE : Self Tracking Entities, c’est à dire qu’elles embarquent la logique de Tracking. Et qu’en est il du lazy loading? Là par contre, si le lazy loading est un point crucial pour vous alors cette solution n’est pas faite pour vous, ou bien vous allez vous embarquer dans un développement custom.

Comment tester que le “Self Tracking” marche?

Pour tester il suffit de charger une entité de la base de données, modifier une de ses propriétés et appeler le SaveChanges du context en cours, si la modification est sauvegardée en base de données c’est que le Tracking de changement a bien fonctionné.

Récapitulons

Nous avons trois manières de travailler avec Entity Framework dans une applications n-tiers:

1 – Utiliser les entités Entity Framework (non POCO) dans toutes les couches de notre application :

- C’est mal !!! pour diverses raisons que nous avons parcouru dans un précédent article 

- Pas de problème de sérialisation des entités via un service WCF

- Nous Bénéficions du tracking de changements et du Lazy Loading

2 -  Utiliser des entités POCOs avec génération de proxy et le Template T4 C# POCO Entity Generator :

- Problème de sérialisation des entités via un service WCF

- Nous Bénéficions du tracking de changements et du Lazy Loading

3 -  Utiliser des entités POCOs sans génération de proxy et le Template T4 C# POCO Entity Generator :

- Pas de problème de sérialisation des entités via un service WCF

- Nous Bénéficions du Self Tracking

- Pas de Lazy loading

Faites votre choix selon vos besoins et vos exigences :)

Vous avez peut être choisi, comme moi, d’utiliser des entités POCO avec Entity Framework 4 et vous vous êtes certainement rendu compte qu’Entity Framework génère des Proxys qui héritent de ces types POCO pour nous les renvoyer par la suite, donc si notre type POCO s’appelle “Person” Entity Framework va nous renvoyer une instance de type “PersonProxy…”.  Jusqu’ici tout roule, mais là ou ça coince c’est lorsque vous essayez d’exposer vos POCO à travers un service WCF. WCF peut renvoyer les types dits “Known types”, ou plus précisément le DataContractSerializer utilisé par WCF ne peut sérialiser que les “Known types” qui sont les types connus par le service, or notre service ne connait pas les proxys et connait uniquement nos types POCO que nous avons déclaré à notre service, de ce fait l’appel de notre service plante au niveau de la sérialisation du résultat à renvoyer au client.

A ce stade nous pouvons avoir deux approches :

La première c’est de dire que de toutes les façons c’est mal d’exposer ces objets métier à travers un service et nous allons contourner le problème en créant des DTO (Data Transfers Object). Nous allons par la suite transformer nos POCO en DTO et exposer ces derniers. Pour que ces transformations de POCO en DTO ne soient pas lourdes et ennuyantes pour les développeurs nous pouvons utiliser un outil de mapping Objet – Objet comme l’auto mapper par exemple.

La deuxième approche consiste tout simplement à dire “Je veux pouvoir exposer mes objets métiers via WCF”. Dans ce cas nous allons nous aider de la classe DataContractResolver qui va nous permettre d’interagir avec les phases de sérialisation / dé sérialisation, nous allons donc en profiter pour mapper le type proxy généré à notre type POCO lors de ces deux phases. Je vous laisse donc lire le post de l’équipe ADO.NET pour voir le code de la solution complète et les explications qui vont avec.

Conclusion

Je déplore vraiment tous ces petits manques dans EF4 (le manque décrit ci-dessus mais aussi celui décrit dans le dernier post) mais ce qui est rassurant c’est que l’équipe ADO.NET semble à l’écoute et est très réactive puisqu’elle propose toujours des “Work around”