Quel problème est Microsoft tenter de résoudre toutes ces stratégies d'accès aux données?

Ils essaient de résoudre le problème de la manière d'augmenter la part des ventes et de la part de marché. À cette fin, divers groupes de Microsoft tentent d'attaquer le problème de la manière d'obtenir plus de développeurs et d'utilisateurs finaux en utilisant leurs produits. Différents groupes proposent différentes technologies et comme une grande entreprise, Microsoft lance la maintenance des technologies alignées et des groupes travaillant vers la même fin. De plus, les technologies de nouvelles technologies qui devaient rester (ou mieux encore, définir) le rythme et continuer à soutenir les technologies plus anciennes que leurs clients ont investi. Le résultat final pour toute sorte de grande entreprise raisonnablement grande, y compris Microsoft, est une sélection de sélections technologiques quelque peu embrouillées.

Votre confusion est notre frustration. Beaucoup d'entre nous qui font ces décisions d'architecture pour nos sites Web ont jeté nos mains avec le manque de clarté de Microsoft et de bonnes pratiques de développement sur cette question.

Mon équipe a certainement été brûlée par Linq2SQL.

Nous construisons maintenant notre site Web avec une approche de conception axée sur le domaine et spécifiquement l'architecture d'oignon de Palermo ( http://jeffreypalermo.com/blog/the-onion-architecture-par-1/ ). Les objets métier ne sont que des pocos et n'ont aucune dépendance sur les infrastructures.

L'infrastructure est maintenant traitée par NHibernate et un orme laminé sur mesure pour notre CMS. Les coûts de démarrage douloureux pour ceux-ci ont été très dépassés par la connaissance que la Communauté continuera de déplacer NHibernate dans la meilleure direction et nous contrôlons la source à notre orèse. Pire vient pire et Microsoft publie quelque chose de vraiment convaincant qui fonctionne dans une architecture DDD, nous devons simplement réécrire notre couche d'infrastructure.

Je ne vois pas le point de cette question. En fait, c'est un peu trollish.

• ADO.NET est la technologie d'accès à la carte d'origine de .NET 1.0. Il n'appartient clairement aucune discussion sur les nouvelles stratégies d'accès aux données
• LINQ à SQL est l'un des fournisseurs de Linq d'origine. Il fournit un mappage unique entre les structures de base de données et les types utilisés dans un programme. Il était censé travailler avec SQL Server
• ADO.NET Entity Framework est plus flexible. Il était destiné à travailler avec n'importe quel fournisseur Ado.net et possède une couche de mappage, de sorte que le programme fonctionne avec des classes plus proches d'être des entités commerciales que des tables de base de données. Par exemple, une seule entité peut inclure des données de plusieurs tables. Microsoft a décidé de dépenser plus d'efforts sur EF que sur Linq à SQL.
• Ado.net Data Services est une couche de services sur EF. Si vous alliez produire votre propre service pour ne rien faire de plus que d'exposer vos données, c'est un pari décent. Il utilise une interface de repos et peut exposer les données au format Atom.
• asp.net Les données dynamiques ne sont pas une stratégie d'accès aux données. Voir http://www.asp.net/dynamicdata/ .

  Les distinctions sont suffisamment claires pour que une quantité triviale de recherche ne les aurait pas rendue claire.

Ils ont eu une stratégie de données pour les âges. En fait, vous pouvez et devriez rechercher "Stratégie d'accès aux données Microsoft" et vous trouverez des liens anciens et nouveaux (c'est-à-dire l'année 1998 et leur stratégie OLDED).

Je pense que ce que vous cherchez est ICI de l'année 2007 que même si l'on a 2 ans est sur XML, ADO.NET, DATA, LINQ, SQL Server, Visual Studio Orcas, Cadre d'entité ... Ils traitent de la question Microsoft a-t-il une stratégie d'accès aux données? :

Oui, il s'avère que nous faisons. Microsoft envisage une plate-forme de données d'entité qui permet aux clients de définir un commun Modèle de données d'entité entre les services de données et des applications. Les données d'entité La plate-forme est une vision multi-libération, Avec les futures versions de rapports Outils, réplication, définition de données, Sécurité, etc. Tous sont construits autour un modèle de données d'entité commune. ...

mike pizzo, architecte, données Programmabilité

J'espère que ça vous aide.

Je trouve l'article de http://msdn.microsoft.com/ EN-US / MAGAZINE / CC700331.ASPX Une belle introduction technique au cadre d'entité si vous n'êtes pas familier avec les concepts sous-jacents.

Voici une section pertinente pour cette question en expliquant certaines des objectifs et de la relation d'EF à ADO.NET ...

Le cadre d'entité ADO.NET est une évolution de ADO.NET et la première mise en œuvre concrète de l'EDM, fournissant un niveau d'abstraction plus élevé lors du développement de la base de données relationnelle. Dans la version 1.0, l'équipe s'est concentrée sur la création de la base d'une plate-forme, plus qu'une simple orme, qui permettra aux développeurs de travailler contre un modèle conceptuel ou objet avec une cartographie très flexible et la capacité d'accueillir un degré élevé. de divergence du magasin sous-jacent.

Ce degré élevé de flexibilité et de divergence du magasin sous-jacent est la clé pour permettre à la base de données et aux applications d'évoluer séparément. Lorsqu'un changement est effectué dans le schéma de base de données, l'application est isolée à partir de la modification par le cadre d'entité et vous n'êtes souvent pas obligé de réécrire les parties de l'application, mais simplement de simplement mettre à jour les fichiers de mappage si nécessaire pour accueillir le changement.

Pour commencer l'évolution de la plate-forme ADO.NET, le cadre d'entité est construit en plus du modèle de fournisseur ADO.NET 2.0 existant, les fournisseurs existants étant mis à jour légèrement pour prendre en charge la nouvelle structure d'entité et la fonctionnalité ADO.NET 3.5. Nous avons choisi de mettre en œuvre au-dessus du modèle de fournisseur ADO.NET existant afin de garantir un modèle de fournisseur familier à la communauté de développement.