Comme personne des parties désintéressées n'a encore laissé de commentaires, nous essaierons de publier des commentaires aussi neutres que possible.
Devart a un historique de support EF plus long - depuis le 30 août 2007. Au cours de ces deux années, nous avons pris en compte de nombreux rapports de bogues et demandes d'utilisateurs. Nous avons également créé et livré avec nos produits Entity Developer
- un puissant outil de conception.
Nous ne pouvons pas appeler notre support Entity Framework pour Oracle un support idéal - cet ORM a été initialement conçu pour MS SQL Server, donc la possibilité de prendre en compte les merveilles d'autres SGBD est considérablement limitée. Il suffit de mentionner uniquement le CROSS APPLY et OUTER APPLY problème
.
Mais, malgré ces problèmes, la plupart de nos utilisateurs sont capables de travailler avec Entity Framework avec succès et confortablement.
Ce sera suffisant pour le dire, mais vous avez mentionné "les applications critiques de l'entreprise". Dans ce cas, nous vous recommandons de jeter un coup d'œil à notre implémentation LINQ to SQL spécifique à Oracle - LINQ vers Oracle
.
LINQ to SQL ne prétend pas construire des solutions inter-bases de données et permet donc de prendre en considération les particularités d'un SGBD séparé, Oracle en particulier. Contrairement à Entity Framework, où nous n'avons qu'un contrôle partiel sur les requêtes SQL générées, dans le cas de LINQ to Oracle, nous avons un contrôle total sur le processus. Ce fait nous donne la possibilité de générer des requêtes spécifiques à Oracle rapides et valides et accélère également le processus de correction et d'amélioration des bogues.
Dans le cas de bases de données Oracle héritées, EF est généralement difficile à appliquer, contrairement à LINQ to Oracle.
Le travail de conception avec le modèle LINQ to Oracle est également effectué à l'aide de Entity Developer.
