Da noch niemand von uninteressierten Parteien Kommentare hinterlassen hat, werden wir versuchen, so neutral wie möglich zu kommentieren.
Devart hat eine längere EF-Supportgeschichte – seit dem 30. August 2007. Während dieser zwei Jahre haben wir zahlreiche Fehlerberichte und Benutzeranfragen berücksichtigt. Wir haben auch Entity Developer
erstellt und mit unseren Produkten ausgeliefert - ein leistungsstarkes Design-Time-Tool.
Wir können unsere Entity Framework-Unterstützung für Oracle nicht als ideal bezeichnen - dieses ORM wurde ursprünglich für MS SQL Server entwickelt, daher ist die Möglichkeit, die Wunder anderer DBMSs zu berücksichtigen, erheblich eingeschränkt. Es reicht aus, nur die zu erwähnen CROSS APPLY und OUTER APPLY Problem
.
Aber trotz dieser Probleme sind die meisten unserer Benutzer in der Lage, erfolgreich und komfortabel mit Entity Framework zu arbeiten.
Das reicht aus, aber Sie haben "kritische Unternehmensanzeichen" erwähnt. In diesem Fall empfehlen wir Ihnen, einen Blick auf unsere Oracle-spezifische LINQ to SQL-Implementierung zu werfen - LINQ zu Oracle
.
LINQ to SQL erhebt nicht den Anspruch, datenbankübergreifende Lösungen zu bauen und ermöglicht somit die Berücksichtigung von Eigenheiten eines separaten DBMS, insbesondere von Oracle. Im Gegensatz zu Entity Framework, wo wir nur teilweise Kontrolle über die generierten SQL-Abfragen haben, haben wir im Fall von LINQ to Oracle die volle Kontrolle über den Prozess. Diese Tatsache gibt uns die Möglichkeit, schnelle und gültige Oracle-spezifische Abfragen zu generieren, und beschleunigt auch die Fehlerbehebung und den Verbesserungsprozess.
Bei älteren Oracle-Datenbanken ist EF normalerweise schwer anzuwenden, im Gegensatz zu LINQ to Oracle.
Designzeitarbeit mit dem LINQ to Oracle-Modell wird auch mit Entity Developer durchgeführt.
