Dans ce cas, si c'est une technologie prometteuse (et ça n'engage que toi, moi je ne vois pas où est l'évolution de faire du mapping simple, à part linq qui est plus "sexy", mais là encore, c'est plus de la forme que du vrai fonds)

Je crois aussi d'après l'abondante doc marketing que nous recevons de Microsoft que Microsoft fonde sa stratégie .NET dans une adoption massive sur des projets d'entreprise de grosse envergure.
Cela a du sens car :
Ca justifie le discours de la scalabilité (désolé, je n'ai toujours pas trouvé de traduction appropriée) des plateformes techniques
Ca reste le meilleur moyen de faire adhérer à une technologie un vaste socle de développeurs

Donc oui, je comprends leurs "positions", et quand bien même je ne les comprends pas il me reste deux solutions :
- Faire avec, et c'est précisemment là que la communauté doit avoir un rôle autre que de faire du péninsulaire et construire ce pont manquant entre l'éditeur et ses clients
- Utiliser une autre techno.

Effectivement , Microsoft fait de gros efforts sur la communauté (CTP, Beta, formations).

Je ne suis pas un pro ou anti microsoft. J'ai juste une activité qui est basée sur leur production; et l'expérience m'a appris qu'il est toujours temps de ne pas adopter à leur sortie ce que microsoft annonce comme le standard du futur.(eg. : Vista; AdoVnext, Object spaces, J#, etc,etc...)

Cela dit en passant pour revenir au fonds du sujet, je trouve aussi qu'ils peuvent avoir des concepts brillants, linq en est un.

Si je devais synthétisé ce que je pense de Microsoft et où Linq en est un excellent exemple; la R&D est toujours excellent (idem, il suffit d'aller voir Chess), les départements d'ingénierie qui vont fournir une implémentation plus orientée développement d'application sont dans certains cas complêtement éloignés du quotidien des développeurs.

Quand je dis EF est un vide intersidéral; je parle d'un point de vue "client" :
- Linq n'est pas EF, donc cette fonctionnalité si agrèable à utiliser n'est pas due à la conception d'EF
- Le designer est propriétaire est sa manipulation n'est pas aisée
- Il mappe des tables, mais ne permet pas de faire du vrai design objet de persistance
- La premiére version ne pouvait même pas fonctionner avec WCF (un comble je trouve --> "perseus")
- Les vrais problèmatiques de la persistence (celles que moi et tous les autres développeurs, architectes ont depuis quelques années sur les développement en couche) sont peu détaillée, peut être gérée mais pas clairement.
- les providers de données sont absents
- Il n'a finalement pas aujourd'hui beaucoup plus d'intérêt que Linq to Sql, et pourtant tous les projets qui ont utilisé Linq To Sql sont en voie d'obsolescence après seulement 1 ans d'existence. (Là encore, c'est faire peu de cas de la communauté que de prendre des orientations aussi drastiques) et son seul vrai intérêt est justement Linq.

Oui, mais Linq aujourd'hui n'est pas approprié à contrôler des stratégies de chargement. Finalement, si tu as une approche statefull c'est génial, si tu as une approche stateless, tout de suite, ça couine. Alors que l'ESB qu'est WCF encourage à faire du SOA donc par essence du stateless...Est là je ne suis plus...

Et effectivement, l'apport de Linq perd de l'attrait : ca devient une fonctionnalité sympathique et puissante, mais elle n'apporte pas de réponse concrête a mes problèmatiques d'architecture. Pire ca pourrait le reléguer en "nice to have".

Et au quotidien, le Framework 3.5 a amené bien des choses que j'utilise au quotidien et qui m'apporte plus que Linq. (Lcg, Types anonymes, méthodes d'extension, lambda....).
Je sais c'est hors contexte, mais j'aime bien expliquer ma position sur un sujet. (Même si tout mérite bien plus que 10 phrases, j'ai horreur de simplifier, mais bon..)