Symposium DNG - Entity Framework et Linq
Par Jean-Baptiste le jeudi 14 février 2008, 18:04 - Code - Lien permanent
Le lecteur attentif aura sans doute remarqué que j'ai sauté la conférence sur Volta dans l'ordre de mes billets. Pourquoi? Parce que la techno étant très jeune je ne suis pas sur de pouvoir faire beaucoup de commentaires intéressants dessus, et du coup Fabien à dit à peu prêt tout ce qu'il y avait à dire sur le sujet
Bien attaquons ce billet donc. Pour rappel, cette session avait pour but de présenter Linq et Entity Framework d'une manière plus architecturale que technique.
L'ensemble était globalement très intéressant, car la grande force du symposium reste quand même de présenter les technos d'un oeil critique, et en comparant à ce qui se fait ailleurs (la tendance de Microsoft étant bien souvent de donner l'impression d'avoir inventer des concepts qui existent depuis une éternité chez la concurrence).
Donc que dire sur Entity Framework? Déjà, nous pouvons dire qu'il tente de faire plus que le boulot de mapping O/R, et qu'il essaye également de modéliser le domaine.
Nous pouvons dire également qu'il se base sur la génération de code, à la différence d'un nhibernate qui se base sur des proxys dynamiques. Cela se traduit plus concrètement par une grande dépendance à l'outil plus une intrusion non négligeable dans nos objets métiers. Par exemple si on a une classe Customer qui contient une collection d'Orders, on se retrouve avec une propriéts "IsLoaded" pour voir sur les orders ont été chargés, ainsi du coup qu'une méthode Load() pour aller les chercher. Niveau transparence de la persistence, on a fait beaucoup mieux. Sinon Entity Framework gère comme tout le monde les différentes stratégies de peristence de l'héritage.
Pour résumer, Entity Framework a l'air de s'orienter plus vers une utilisation en partant des tables; ce qui dans une approche DDD est une hérésie, mais dans le cadre de la gestion d'une base legacy est toujours intéressant; et il faut bien savoir que son approche par génération de code va le rendre difficilement remplaçable dans votre projet. De plus sont approche encore une fois très WISIWIG génère du code à mon sens pas très heureux ni très bien organisé (cf cet exemple) Avec des notions en main, c'est à vous de juger ensuite s'il est pertinent de l'utiliser sur un projet, mais très personnellement j'aurai tendance à encore favoriser largement NHibernate.
Le temps fort de cette session aura sans douté été le benchmark entre les différents O/R mapper disponibles en .NET. La grande surprise a sans doute été de se rendre compte que contrairement à la croyance populaire, NHibernate est loin d'afficher des perfs anémiques comparé à de la génération de code. C'est du coup presque à se demander s'il y a le moindre intérêt à utiliser entity framework. Parmi les autres outils benchmarkés, notons la présence de Genome qui étaient loin derrière la concurrence, et d'EUSS dans ses versions dynamiques et générées, affichant des perfs dans la "norme". Je dois avouer que je ne le connaissais pas, donc il va falloir que je me document un plus sur lui. Il y en va de même pour LLBLGen.
Pour revenir à Linq, je dois dire que vu la nouveauté du concept, j'ai encore du mal à intégrer l'idée à mes architectures actuelles, et qu'il va sans doute falloir attendre pas mal de retour pour réussir à voir comment l'utiliser au mieux; mais il est vrai qu'il a posé des bases sur une manière complètement nouvelle de voire les choses.



Commentaires
Très bon résumé. Comme je ne sentais mal à l'aise pour parler de ces deux outils et que je partage en de nombreux points ton opinion, je m'abstiendrai de bloguer sur le sujet
Je tiens juste à dire que, concernant Linq, j'attends Linq2NHibernate avec impatience.