Lettre ouverte à Microsoft à propos d’Entity Framework
David Laribee a laissé un message sur le groupe de discussion ALT.NET, indiquant que plusieurs personnes avaient travaillé à la rédaction d’une lettre ouverte à Microsoft, au sujet de sa solution ORM en devenir : Entity Framework.
Cette lettre, qui prend forme d’une pétition, a pour but d’attirer l’attention sur les principales faiblesses du framework. Il ne s’agit pas d’une condamnation, mais plutôt d’une synthèse argumentée qui tente de regrouper les critiques ayant mobilisé le plus de voix au cours des derniers mois.
Si vous pensez que les remarques sont pertinentes, et gagneraient à être considérées par le géant, alors vous pouvez laisser votre signature :
ADO.NET Entity Framework vote of no confidence
- Inordinate focus the data aspect of entities leads to degraded entity architectures
- Excess code needed to deal with lack of lazy loading
- Shared, canonical model contradicts software best practices
- Lack of persistence ignorance causes business logic to be harder to read, write, and modify, causing development and maintenance costs to increase at an exaggerated rate
- Excessive merge conflicts with source control in team environments
Toutefois, sachez que Microsoft est déjà à l’écoute, comme en atteste un post de Danny Simmons (de l’équipe ADO.NET). On y apprend qu’un concile consultatif aura lieu en Juillet pour faire le point sur les récentes productions de l’équipe Data Programmability chez Microsoft : Entity Framework, LINQ to SQL, ADO.NET Data Services, etc. Plusieurs personnalités de la communauté seront invitées (et consultées, donc), parmi lesquelles Martin Fowler, Eric Evans ou encore Jimmy Nilsson.
On peut donc douter de l’impact d’une telle pétition dans un ce contexte. Je trouve pour ma part qu’il s’agit d’un bon résumé, dont la lecture ne peut qu’être instructive.
Une nouvelle annonce : Hier a commencé le développement de la version 2.0 de l’Entity Framework. Tim Mallalieu, Program Manager, indique sur un nouveau blog que le design de cette nouvelle version sera transparent. Reste à voir ce que ça va donner, mais c’est toujours bon signe.
Articles
Codingly 
Je ne connais pas bien Entity, mais d’après ce que je lis dans la pétition, je pense que Microsoft on choisi une mauvaise approche.
D’après ce que je comprend, les « Entities » serait des classes générées, impossible à étendre (pas partiel) et donc difficile à incorporer dans le modèle métier. Très franchement, on dirait des Datasets…
Le Lazy-load est à mon avis aussi un fonctionnalité très très importante pour un ORM. Ceci dit, j’ai eu plusieurs fois le même problème qui m’empêchait de l’utiliser:
Dans une application multi-couche avec exposition des services (en Web-services par exemple), le serveur ne peux pas retourner un objet « partiellement » chargé au client.
Mon application « cliente » ne bénéficie pas du Lazy-load, et ne pourra d’ailleurs jamais en bénéficier car elle n’a pas accès à la base de données.
En remoting, en re-inventant un « pseudo-ORM », j’ai fait en sorte que les objets partiellement chargé possède une référence vers le service (MarshallByRefObject), et peuvent ainsi charger d’autre propriétés à la demande.
Est-ce que tu as déjà rencontrer le problème? Comment l’as-tu résolu?
A chaud, je me demande si l’AOP coté client ne pourrait pas s’en charger…
PS: si t’as le temps, peux-tu nous résumer cette lettre pour ceux qui n’ont pas le temps de la lire (ou qui n’aime pas l’anglais)? Peux-tu aussi nous donner ton avis/retour d’expérience? :)
Je n’ai jamais utilisé sérieusement Entity Framework, donc je suis très clairement mal placé pour te décrire en détail son fonctionnement. Ceux qui ont rédigé la lettre, par contre, ont un avis éclairé sur la question.
Je peux juste te dire qu’il y a un monde entre les datasets et Entity Framework. Tu manipules bien des objets, fortement typés, mais qui restent dépendants d’EF. D’où la grogne des adeptes du DDD et de la Persistance Ignorance. Note au passage que l’extensibilité d’une classe partielle est toute relative. Je préfère généralement parler d’extensibilité lorsqu’il est possible de découpler, d’injecter, de surdéfinir, d’hériter, etc.
Le lazy load est supporté par Entity Framework, seulement, il est explicite. Il faut donc s’appuyer sur les méthodes
Load()etIsLoaded(). C’est considéré comme un vrai problème par ceux qui sont habitués aux solutions ORM supportant le lazy loading automatique, comme NHibernate.Pour ton problème, je ne l’ai pas rencontré mais je vois très bien de quoi tu parles :’) Cela fait partie d’un grand ensemble de questions relatives à la compatibilité du DDD avec SOA et autres principes d’architectures distribuées… (Une discussion intéressante à ce sujet a lieu actuellement sur la ML ALT.NET : Does WCF/SOA lead to Anemic Domain Models)
Dans ton cas, je pense justement que le lazy loading explicite pourrait être une piste ; je suppose d’ailleurs que tu gérais ça au niveau client, en laissant le proxy charger explicitement ses branches. Au niveau du code utilisant le proxy par contre, ça devait être transparent. L’AOP pourrait probablement adresser le problème, mais ça serait juste un moyen de ne pas avoir à répéter les appels aux méthodes de chargement explicite, ce qu’il est déjà possible d’encapsuler directement dans les proxies. Est-ce bien ça que tu imaginais ?
En ce qui concerne Entity Framework, je vous conseille le blog de Matthieu Mezil, qui est à ma connaissance un des meilleurs blogs francophones traitant régulièrement du sujet.
Je pense que j’ai une bonne connaissance de l’Entity Framework et je ne suis pas d’accord avec la pétition. Pourquoi ?
Premièrement, parce que c’est la première version et que j’ai plutôt tendance à me réjouir de tout ce qu’elle apporte plutôt que de regretter ce qu’elle n’apporte pas encore. Ceci étant dit, les classes générées SONT partielles. De plus, même si la v1 ne supporte pas la Persistance Ignorance (POCO), IPOCO lui est supporté. Cela signifie donc qu’on n’est pas obligé d’utiliser le code généré pour lequel les entités héritent d’une classe de base du framework mais qu’on peut utiliser nos propres classes à condition de leur faire implémenter quelques interfaces.
Quant-au Lazy Loading, comme le dit Romain, il faut utiliser la méthode Load et, petite correction, la propriété IsLoaded, ce qui, à mon sens, n’est pas aberrant.
Je pense que l’Entity Framework, même s’il ressemble beaucoup à NHibernate n’a pas pour vocation de le copier aussi je suis un peu surpris de l’excessivité de l’argument.
Enfin, il faut noter qu’avec la V2, EF supporte POCO et le lazy loading automatique.
Après l’avoir beaucoup utilisé, mon avis personnel et que l’EF v1 est vraiment utilisable en l’état et je conseille vivement de l’utiliser au vu de tout ce qu’il permet et apporte.
Je pense également que c’est un framework qui va prendre de plus en plus d’importance (ex : Reporting services utilisant un EDM, l’intégration avec ADO.NET Data Services, etc.). Cependant, j’en conviens, il y a encore des améliorations à apporter. Pour info, j’ai déjà discuté avec Daniel Simmons de ce que je souhaiterais voir dans la V3…
Pour conclure, je n’ai pas signé la pétition et je ne le ferai pas.
P.S. : Romain, merci pour le lien :-)