Como nadie de las partes desinteresadas no ha dejado ningún comentario todavía, intentaremos publicar un comentario lo más neutral posible.
Devart tiene un historial de soporte de EF más largo, desde el 30 de agosto de 2007. Durante estos dos años, hemos tenido en cuenta numerosos informes de errores y solicitudes de usuarios. También hemos creado y enviado con nuestros productos Entity Developer
- una poderosa herramienta de tiempo de diseño.
No podemos llamar ideal a nuestro soporte de Entity Framework para Oracle:este ORM se diseñó inicialmente para MS SQL Server, por lo que la posibilidad de tener en cuenta las maravillas de otros DBMS es significativamente limitada. APLICACIÓN CRUZADA y APLICACIÓN EXTERNA problema
.
Pero, a pesar de estos problemas, la mayoría de nuestros usuarios son capaces de trabajar con Entity Framework con éxito y comodidad.
Eso será suficiente para decir, pero ha mencionado "aplicaciones empresariales críticas". En este caso, le recomendamos que eche un vistazo a nuestra implementación de LINQ to SQL específica de Oracle - LINQ a Oracle
.
LINQ to SQL no pretende crear soluciones de bases de datos cruzadas y, por lo tanto, permite tener en cuenta las peculiaridades de un DBMS separado, Oracle en particular. A diferencia de Entity Framework, donde solo tenemos control parcial sobre las consultas SQL generadas, en el caso de LINQ to Oracle tenemos control total sobre el proceso. Este hecho nos brinda la oportunidad de generar consultas específicas de Oracle rápidas y válidas y también acelera el proceso de mejora y corrección de errores.
En el caso de las bases de datos heredadas de Oracle, EF suele ser difícil de aplicar, a diferencia de LINQ to Oracle.
El trabajo de tiempo de diseño con el modelo LINQ to Oracle también se realiza mediante Entity Developer.
