Aangezien niemand van belangeloze partijen nog geen opmerkingen heeft achtergelaten, zullen we proberen een zo neutraal mogelijke opmerking te plaatsen.
Devart heeft een langere geschiedenis van EF-ondersteuning - sinds 30 augustus 2007. Gedurende deze twee jaar hebben we rekening gehouden met talrijke bugrapporten en verzoeken van gebruikers. We hebben ook onze producten gemaakt en geleverd met Entity Developer
- een krachtige tool voor ontwerptijd.
We kunnen onze Entity Framework-ondersteuning voor Oracle niet ideaal noemen - deze ORM is oorspronkelijk ontworpen voor MS SQL Server, dus de mogelijkheid om rekening te houden met de wonderen van andere DBMS'en is aanzienlijk beperkt. Het is voldoende om alleen de CROSS APPLY en OUTER APPLY probleem
.
Maar ondanks deze problemen zijn de meeste van onze gebruikers in staat om succesvol en comfortabel met Entity Framework te werken.
Dat is voldoende om te zeggen, maar u hebt het gehad over "kritieke enterprise allpications". In dit geval raden we u aan om onze Oracle-specifieke LINQ to SQL-implementatie te bekijken - LINQ naar Oracle
.
LINQ to SQL pretendeert niet om cross-database oplossingen te bouwen en maakt het daarom mogelijk om rekening te houden met eigenaardigheden van een apart DBMS, Oracle in het bijzonder. In tegenstelling tot Entity Framework, waar we slechts gedeeltelijke controle hebben over de gegenereerde SQL-query's, hebben we in het geval van LINQ to Oracle volledige controle over het proces. Dit feit geeft ons de mogelijkheid om snelle en geldige Oracle-specifieke vragen te genereren en versnelt ook het oplossen van bugs en het verbeteringsproces.
In het geval van legacy Oracle-databases is EF meestal moeilijk toe te passen, in tegenstelling tot LINQ op Oracle.
Ontwerptijdwerk met het LINQ to Oracle-model wordt ook uitgevoerd met behulp van Entity Developer.
