Welches Problem versucht Microsoft mit all diesen Datenzugriffsstrategien zu lösen?

Question

Es scheint viele verschiedene Datenzugriffsstrategien von Microsoft zu geben. Es gibt "klassische" ADO.NET, Linq2Sql, ADO.NET Entity Framework, ADO.NET Data Services, ADO.NET Dynamische Daten. Ich bin mir sicher, dass ich etwas verpasst habe. Mir scheint, dass es viel Verwirrung darüber gibt, wo jedes Framework in die Architektur einer Anwendung passt. Welches Problem versucht Microsoft mit all diesen Datenzugriffsmethoden zu lösen?

Answer 1

Sie versuchen, das Problem zu lösen, wie man Verkäufe und Marktanteil erhöht. Zu diesem Zweck versuchen verschiedene Gruppen innerhalb von Microsoft, das Problem anzugehen, wie mehr Entwickler und Endbenutzer ihre Produkte nutzen können. Unterschiedliche Gruppen kommen mit unterschiedlichen Technologien, und wie jedes große Unternehmen kämpft Microsoft darum, dass seine Technologien ausgerichtet bleiben und Gruppen auf dasselbe Ziel hinarbeiten. Hinzu kommt, dass neuere Technologien das Tempo halten (oder besser noch festlegen) und weiterhin ältere Technologien unterstützen müssen, in die ihre Kunden investiert haben. Das Endergebnis für jede Art von Unternehmen, einschließlich Microsoft, ist eine etwas verwirrende Auswahl an Technologie-Auswahlen.

Answer 2

Sie Verwirrung ist unsere Frustration. Viele von uns, die diese Architekturentscheidungen für unsere Websites treffen, haben sich mit Microsofts mangelnder Klarheit und guten Entwicklungspraktiken in diesem Bereich herumgeschlagen.

Mein Team wurde sicherlich von Linq2Sql verbrannt.

Wir bauen jetzt unsere Website mit einem Domain Driven Design Ansatz und speziell Palermo Onion Architecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Business-Objekte sind nur POCOs und haben keine Abhängigkeiten von der Infrastruktur.

Die Infrastruktur wird jetzt von NHibernate verarbeitet und ein benutzerdefiniertes Roll-ORM für unser CMS. Die schmerzhaften Startkosten für diese wurden weit übertroffen durch das Wissen, dass die Community NHibernate weiterhin in die beste Richtung bewegen wird und wir die Quelle für unser ORM kontrollieren. Schlimmeres kommt hinzu und Microsoft bringt etwas wirklich überzeugendes heraus, das in einer DDD-Architektur funktioniert. Wir müssen nur unsere Infrastruktur-Ebene neu schreiben.

Answer 3

Ich sehe den Punkt dieser Frage nicht. In der Tat ist es ein bisschen Troll.

• ADO.NET ist die ursprüngliche Datenzugriffstechnologie von .NET 1.0. Es gehört eindeutig zu keiner Diskussion über neue Datenzugriffs- "Strategien".
• LINQ to SQL ist einer der ursprünglichen LINQ-Anbieter. Es bietet eine Eins-zu-eins-Zuordnung zwischen Datenbankstrukturen und den in einem Programm verwendeten Typen. Es sollte mit SQL Server arbeiten
• ADO.NET Entity Framework ist flexibler. Es sollte mit jedem ADO.NET-Provider zusammenarbeiten und verfügt über eine Zuordnungsebene, sodass das Programm mit Klassen arbeitet, die näher an Geschäftsentitäten als an Datenbanktabellen liegen. Zum Beispiel kann eine einzelne Entität Daten aus mehreren Tabellen enthalten. Microsoft hat sich entschieden, mehr Aufwand für EF als für LINQ to SQL zu betreiben.
• ADO.NET Data Services ist eine Services-Schicht über EF. Wenn Sie Ihren eigenen Dienst produzieren würden, um nur Ihre Daten preiszugeben, dann ist das eine gute Wette. Es verwendet eine REST-Schnittstelle und kann die Daten im ATOM-Format verfügbar machen.
• ASP.NET Dynamische Daten sind keine Datenzugriffsstrategie. Siehe http://www.asp.net/dynamicdata/.

Die Unterscheidungen sind klar genug, dass eine triviale Menge an Forschung sie klar gemacht hätte.

Answer 4

Sie hatten eine Datenstrategie für Alter. In der Tat können und sollten Sie "Microsoft Data Access Strategy" suchen und finden Sie Links alt und neu (d. H. Jahr 1998 und ihre OLEDB-Strategie).

Ich denke, was Sie suchen, ist here aus dem Jahr 2007, dass, obwohl 2 Jahre alt ist über XML, ADO.NET, Daten, LINQ, SQL Server, Visual Studio Orcas, Entity Framework ... sie adressieren Frage Hat Microsoft eine Datenzugriffsstrategie?:

Ja, es stellt sich heraus, dass wir es tun. Microsoft sieht eine Entity Data Platform vor, die Kunden ermöglicht, ein gemeinsames Entity Data Model über Datenservices und Anwendungen zu definieren. Die Entitätsdaten Plattform ist eine Multi-Release-Vision, mit zukünftigen Versionen der Berichterstattung Tools, Replikation, Datendefinition, Sicherheit, etc. alle um ein gemeinsames Entity Data Model gebaut. ...

Mike Pizzo, Architekt, Daten Programmierbarkeit

Ich hoffe, es hilft.

Answer 5

Ich finde den Artikel unter http://msdn.microsoft.com/en-us/magazine/cc700331.aspx eine nette technische Einführung in Entity Framework, wenn Sie nicht mit den zugrunde liegenden Konzepten vertraut sind.

Hier ist ein Abschnitt, der auf diese Frage relevant ist, einige EF Ziele und die Beziehung zu ADO.Net erklären ...

Das ADO.NET Entity Framework eine Weiterentwicklung von ADO.NET ist und die erste Konkrete Implementierung des EDM, die bei der Entwicklung gegen eine relationale Datenbank ein höheres Abstraktionsniveau bietet. In der Version 1.0 konzentrierte sich das Team auf den Aufbau einer Plattform, mehr als nur ein einfaches ORM, das es Entwicklern erlaubt, gegen ein Konzept- oder Objektmodell mit einem sehr flexiblen Mapping und der Fähigkeit, ein hohes Maß an Komplexität zu erreichen, zu arbeiten der Divergenz von dem zugrunde liegenden Geschäft.

Dieses hohe Maß an Flexibilität und Abweichungen vom zugrunde liegenden Geschäft ist der Schlüssel, um die Datenbank und Anwendungen getrennt entwickeln zu können. Wenn eine Änderung im Datenbankschema vorgenommen wird, ist die Anwendung von der Änderung durch das Entity Framework isoliert, und Sie müssen häufig keine Teile der Anwendung neu schreiben, sondern die Zuordnungsdateien einfach aktualisieren, wenn dies für die Änderung erforderlich ist.

Um mit der Entwicklung der ADO.NET-Plattform zu beginnen, baut das Entity Framework auf dem vorhandenen ADO.NET 2.0-Providermodell auf, wobei vorhandene Anbieter leicht aktualisiert werden, um die neue Entity Framework- und ADO.NET 3.5-Funktionalität zu unterstützen. Wir haben uns dafür entschieden, das vorhandene ADO.NET-Provider-Modell zu implementieren, um ein Provider-Modell zu gewährleisten, das der Entwicklungs-Community vertraut ist.