Ponieważ nikt z bezinteresownych stron nie pozostawił jeszcze żadnych komentarzy, postaramy się publikować jak najbardziej neutralny komentarz.
Devart ma dłuższą historię wsparcia EF - od 30 sierpnia 2007. W ciągu tych dwóch lat wzięliśmy pod uwagę liczne zgłoszenia błędów i prośby użytkowników. Stworzyliśmy również i dostarczamy z naszymi produktami Programista jednostek
- potężne narzędzie czasu projektowania.
Nie możemy nazwać naszego wsparcia Entity Framework dla Oracle idealnym - ten ORM był początkowo zaprojektowany dla MS SQL Server, więc możliwość uwzględnienia cudów innych DBMS jest znacznie ograniczona. Wystarczy wspomnieć tylko o CROSS APPLY i OUTER APPLY problem
.
Ale pomimo tych problemów większość naszych użytkowników może pomyślnie i wygodnie pracować z Entity Framework.
Wystarczy, że wspomniałeś o „krytycznych problemach przedsiębiorstwa”. W tym przypadku zalecamy zapoznanie się z implementacją LINQ to SQL specyficzną dla Oracle — LINQ to Oracle
.
LINQ to SQL nie pretenduje do budowania rozwiązań międzybazowych, a tym samym pozwala na uwzględnienie specyfiki oddzielnego DBMS, w szczególności Oracle. W przeciwieństwie do Entity Framework, gdzie mamy tylko częściową kontrolę nad generowanymi zapytaniami SQL, w przypadku LINQ to Oracle mamy pełną kontrolę nad procesem. Fakt ten daje nam możliwość generowania szybkich i poprawnych zapytań specyficznych dla Oracle, a także przyspiesza proces naprawiania i ulepszania błędów.
W przypadku starszych baz danych Oracle EF zwykle jest trudny do zastosowania, w przeciwieństwie do LINQ to Oracle.
Praca w czasie projektowania z modelem LINQ to Oracle jest również wykonywana przy użyciu Entity Developer.