Poiché nessuno dei partiti disinteressati non ha ancora lasciato alcun commento, cercheremo di pubblicare un commento il più neutro possibile.
Devart ha una cronologia del supporto EF più lunga - dal 30 agosto 2007. Durante questi due anni abbiamo preso in considerazione numerose segnalazioni di bug e richieste degli utenti. Abbiamo anche creato e spedito con i nostri prodotti Entity Developer
- un potente strumento di progettazione.
Non possiamo definire ideale il nostro supporto Entity Framework per Oracle:questo ORM è stato inizialmente progettato per MS SQL Server, quindi la possibilità di tenere conto delle meraviglie di altri DBMS è notevolmente limitata. Basta citare solo il APPLICAZIONE INCROCIATA e APPLICAZIONE ESTERNA problema
.
Ma, nonostante questi problemi, la maggior parte dei nostri utenti è in grado di lavorare con Entity Framework con successo e comodamente.
Sarà sufficiente per dire, ma hai menzionato "alpicazioni aziendali critiche". In questo caso ti consigliamo di dare un'occhiata alla nostra implementazione LINQ to SQL specifica per Oracle - LINQ to Oracle
.
LINQ to SQL non pretende di costruire soluzioni cross-database e quindi permette di prendere in considerazione le peculiarità di un DBMS separato, Oracle in particolare. A differenza di Entity Framework, dove abbiamo solo un controllo parziale sulle query SQL generate, nel caso LINQ to Oracle abbiamo il pieno controllo del processo. Questo fatto ci offre l'opportunità di generare query specifiche Oracle rapide e valide e accelera anche il processo di correzione e miglioramento dei bug.
In caso di database Oracle legacy, EF di solito è difficile da applicare, a differenza di LINQ to Oracle.
Anche il lavoro di progettazione con il modello LINQ to Oracle viene eseguito utilizzando Entity Developer.
