About the Entity Framework
The implementation of
DbSet<> causes the data context to load the database record only once during the
Controller life cycle. Therefore, the performance difference between the system written with pure SQL for the system in Entity Framework becomes negligible if the database is normalized correctly (that is, with unique primary keys and avoiding unnecessary relationships such as tables that are updated from once in never, and can be replaced with
Enums ). Because it is very simple, it is ideal for the beginning of development of a system. The disadvantage is the lack of support for other banks, such as Oracle, for example.
It is a solution older than the Entity Framework, which came from Java when ORM started. It has more configuration options and works better with databases other than SQL Server. However, the approach to Code First is still a bit too prolix, which makes it slower than the Entity Framework to start a project in terms of productivity, being more recommended for large projects that are already implemented and work with large masses of data, which requires fine tuning of the settings.
To what extent is it not advisable to use an ORM?
This part is somewhat opinion-based, but initially I would say there are no restrictions, since ORM frameworks enable pure SQL execution in stages where there are performance bottlenecks. Therefore, neither productivity nor performance is compromised.
Oracle developed your data provider with the Entity Framework , finally. With this, the connectivity problem between Oracle and Entity Framework is over.
A tutorial was also written by the Oracle team to address any questions that might arise in the integration.