Ist ADO.NET EntityFramework das bessere LINQ?

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Ist ADO.NET EntityFramework das bessere LINQ? - Presentation Transcript

    1. Ist ADO.NET EntityFramework das bessere LINQ? VISUAL WORLD, Annaberger Str. 240, 09125 Chemnitz E-Mail: [email_address] , Web: http://www.visual-world.de
    2. Übersicht
      • Einleitung
      • Vorstellung des Referenten
      • LINQ-to-…
      • Idee des Objekt-Relationalen Mappings (ORM)
      • LINQ-to-SQL und ADO.NET Entity Framework (EF)
      • Praktische Beispiele
      • Geschwindigkeitsvergleich zwischen LINQ, EF und Typisierten Datasets
    3. Einleitung
      • Ziele dieses Vortrags
      • Erster Kontakt mit dem Entity Framework und LINQ-to-SQL
      • Unterschied zwischen dem Entity Framework und LINQ-to-SQL aufzeigen
      • Diskussion am späteren Abend 
    4. Vorstellung des Referenten
      • - Robert Meyer
      • Softwareentwickler in der Firma Visual World seit 2007
      • Entwicklung von Individualsoftware im Bereich Geschäftssoftware (ERP, CRM und Warenwirtschaftssysteme)
      • Schwerpunkte:
        • Datenbanken (SQL Server ab 2000)
        • Softwarearchitektur und –optimierung
        • WinForms und WPF
        • Datenzugriffstechnologien
      • Microsoft Certified Professional für .NET 2.0
    5. Themenwahl
      • „ Ist ADO.NET EntityFramework das bessere LINQ?“
      • Was ist falsch an dieser Frage?
      • Wieso dieses Thema?
    6. LINQ-to-…
    7. LINQ-to-…
    8. Idee des Objekt-Relationalen Mappings (ORM)
      • Was ist ein OR-Mapper?
      • „ Objekt-Relationales Mapping ist die Abbildung von Geschäftsobjekten
      • im Hauptspeicher auf Datensätzen in relationalen Datenbanktabellen
      • zum Zwecke der Objektpersistenz“
      • Objekt-Relationales Mapping ist die Abbildung zwischen Objekten und Datensätzen bzw. Klassen und Tabellen.
    9. Idee des Objekt-Relationalen Mappings (ORM)
    10. Idee des Objekt-Relationalen Mappings (ORM)
      • Schlagwörter:
      • Mapping-Szenarien
      • Abfragesprachen
        • Object Query Language (OQL) in VOA und Genome
        • Hibernate Query Language (HQL) in nHibernate
        • Language Integrated Query (LINQ) in Linq-to-Sql und EntityFramework
      • Ladestrategien
        • Lazy Loading
        • Eager Loading
    11. Idee des Objekt-Relationalen Mappings (ORM)
      • Schlagwörter:
      • - Forward Engineering
      • - Reverse Engineering
      • Change Tracking
      • Caching
      • Objektcontainer (ObjectContext, DataContext)
    12. Idee des Objekt-Relationalen Mappings (ORM)
      • Abfragesprachen
      • Jeder OR-Mapper hat eine (eigene) Abfragesprache
      • SQL ist als Abfragesprache nicht geeignet, das sich SQL auf die Datenbankstruktur (Tabellennamen etc.) bezieht.
      • Trend geht zur Language Integrated Query (LINQ), durch die Integration in den Sprachsyntax von C# und Visual Basic 2008
      • LINQ kann durch dokumentierte Schnittstellen auch von Drittanbietern genutzt werden (LINQ-to-MySql, LINQ-to-SAP, LINQ-to-Amazon und viele mehr)
    13. Idee des Objekt-Relationalen Mappings (ORM)
      • Ladestrategien
      • Übernehmen der Entscheidung wann Daten zu laden sind
      • Lazy Loading bzw. Delayed Loading
        • Nachladen von Abhängigkeiten bei Bedarf
        • Standard bei allen OR-Mappern
      • Eager Loading
        • Abhängigkeiten werden direkt mit geladen
        • Muss explizit ausgeführt werden
      • Entscheidungskriterien sind:
        • Datenmenge
        • Werden die Daten wirklich benötigt?
    14. Idee des Objekt-Relationalen Mappings (ORM)
      • Ladestrategien
      • Beispiel für Eager Loading
    15. Idee des Objekt-Relationalen Mappings (ORM)
      • Forward Engineering / Reverse Engineering
      • Forward Engineering (Code First)
        • Wird nicht von allen OR-Mappern unterstüzt (LINQ unterstützt z.B. Forward Engineering, EF nicht)
        • Vorgang: Es werden zuerst die Geschäftsobjekte (Klassen etc.) erstellt und daraus wird danach die Datenbank erstellt.
      • Reverse Engineering (Database First)
        • Wird von vielen OR-Mappern unterstützt (LINQ, EF, nHibernate)
        • Vorgang: Es wird zuerst die Datenbank erstellt und daraus ergeben sich die Geschäftsobjekte
      • Problematik
        • Übernehmen von Änderung im Datenbankschema (z.B. Spaltentypen) in die Geschäftsobjekte (Klassen etc.)
    16. Idee des Objekt-Relationalen Mappings (ORM)
      • Change Tracking
      • ORM-Werkzeuge überwachen Änderungen in den Objekten (Change Tracking)
      • Grund: Beim speichern der Objekte werden nur die veränderten oder neuen Objekte in die Datenbank übernommen.
      • Ein guter OR-Mapper aktualisiert nur die betroffenen Spalten und nicht den ganzen Datensatz in der Datenbank
    17. Idee des Objekt-Relationalen Mappings (ORM)
      • Objektcontainer
      • Ein Objektcontainer hält die Objekte im RAM
      • Objektcontainer werden vor der ersten Abfrage erzeugt
      • Abfrage muss in dem Objektcontainer stattfinden
      • Objektcontainer merken sich den Ausgangszustand eines Objekts
      • Objektcontainer haben je nach OR-Mapper andere Namen z.B.:
        • ObjectContext (im Entity Framework)
        • DataContext (in LINQ-to-SQL)
    18. Idee des Objekt-Relationalen Mappings (ORM)
      • Caching
      • Objektcontainer speichern Objekte zwischen
      • Verhindert unnötiges neu laden der Objekte
      • Einige OR-Mapper legen benutzen hierfür auch den Second Level Cache (z.B. nHibernate)
    19. LINQ-to-SQL und ADO.NET Entity Framework
      • Entstehung:
      • LINQ-to-SQL und das EntityFramework wurden parallel entwickelt
      • LINQ-to-SQL wurde mit dem .NET Framework 3.5 ausgeliefert
      • EntityFramework kam mit dem SP1 für das .NET 3.5 Framework
      • Das EntityFramework ist entstanden aus dem früheren Ansatz „Object Spaces“
      • Das EntityFramework ist keine Weiterentwicklung von LINQ-to-SQL
    20. LINQ-to-SQL und ADO.NET Entity Framework
      • Technische Unterschiede:
      • - LINQ-to-SQL arbeitet direkt auf dem Datenbankschema
      • EntityFramework verwendet die Entity-Relationship-Modellierung (ERM)
      • LINQ-to-SQL hat nur einen Provider zu MSSQL (Nicht-Offenlegung der Schnittstellen), während das EF theoretisch für alle Datenbank nutzbar ist.
      • LINQ-to-SQL unterstützt die Abfragesprache LINQ und direktes SQL, das EF nutzt LINQ Entity SQL (eSQL) und LINQ in Form von LINQ-to-Entities.
      • LINQ-to-SQL unterstützt nur 1:1 Abbildung zwischen Tabellen und Objekten, beim EF sind beliebige Abbildungen möglich.
    21. LINQ-to-SQL und ADO.NET Entity Framework
      • Technische Unterschiede:
      • LINQ-to-SQL unterstützt sowohl Reverse als auch Forward Engineering, EF hingegen unterstützt momentan nur Reverse Engineering.
      • EF und LINQ-to-SQL verwenden in den Designern beide XML, aber absolut unterschiedliche Formate.
    22. LINQ-to-SQL und ADO.NET Entity Framework
      • Gemeinsamkeit:
      • - Sowohl EF als auch LINQ-to-SQL unterstützen Lazy und Eager Loading.
      • In beiden Lösungen hält der Kontext (Objektkontext (EF) und Datakontext (LINQ-to-SQL) die Objekte zusammen.
      • Beide unterstützen den LINQ Syntax
    23. LINQ-to-SQL und ADO.NET Entity Framework
      • Einsatzszenarien:
      • LINQ-to-SQL für einfach Mapping-Szenarien und kleine Anwendungen
      • Entity Framework ist für komplexe Anwendungsfälle gedacht.
      • Entity Framework ist jedoch viel lockerer Verknüpfung als das LINQ-to-SQL Model und kann somit leichter angepasst werden.
    24. Praktische Beispiele
      • Vergleich der Objektmodelle
      • Von LINQ-to-SQL und Entity Framework
    25. Praktische Beispiele
      • Geschwindigkeitsvergleich zwischen
      • Entity Framework
      • LINQ-to-SQL
      • Stark typisierte DataSets
    26. Vorschau Entity Framework
      • Ankündigungen für Entity Framework Version 2 in .NET 4.0
      • Unterstützung von Forward Engineering (kein Round Trip Engineering)
      • Model Definied Functions
      • Unterstützung von Table Valued Functions (TVF)
      • Unterstützung von StoredProcedures (Rückgabe von Scalarwerten z.B. String)
    27. Ende
      • Vielen Dank für Eure Aufmerksamkeit!
      • Quellen: Kontakt:
      • CodeProject (Bilder) Robert Meyer
      • .Net 3.5 Crashkurs (ISBN: 978-3-86645-512-2) [email_address]
      • Diverse Foren https://www.xing.com/profile/Robert_Meyer10

    + .NET User Group Dresden.NET User Group Dresden, 8 months ago

    custom

    1869 views, 0 favs, 2 embeds more stats

    Ist ADO.NET EntityFramework das bessere LINQ?

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 1869
      • 1816 on SlideShare
      • 53 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 3
    Most viewed embeds
    • 27 views on http://www.dd-dotnet.de
    • 26 views on http://dd-dotnet.de

    more

    All embeds
    • 27 views on http://www.dd-dotnet.de
    • 26 views on http://dd-dotnet.de

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories