EF isn't all that useful in Oracle; you have ODP.NET doing all the work anyway.
Why play with yet another layer?
Typically, you cannot find DB developers that are an ace in C# and vise versa. That is a seldom occurrence to say the least. You cannot try to do everything in .NET because it is VERY impractical in most circumstances I have seen in the last 20+ years.
DBA type folks are not interested in seeing anything aside from scripts. Send them the tested SQL scripts for all your objects.
Data is critical, more so than code, yet we all think and talk in terms of process (code). Systems start with requirements. The fewer steps between requirement definition and the production system the better. The first place to make a change to your database should be the requirements document, whatever form that takes, and then there should be no further human interaction. Get it?
EF isn't all that useful in Oracle; you have ODP.NET doing all the work anyway.
Why play with yet another layer?
Typically, you cannot find DB developers that are an ace in C# and vise versa. That is a seldom occurrence to say the least. You cannot try to do everything in .NET because it is VERY impractical in most circumstances I have seen in the last 20+ years.
DBA type folks are not interested in seeing anything aside from scripts. Send them the tested SQL scripts for all your objects.
Data is critical, more so than code, yet we all think and talk in terms of process (code). Systems start with requirements. The fewer steps between requirement definition and the production system the better. The first place to make a change to your database should be the requirements document, whatever form that takes, and then there should be no further human interaction. Get it?
.