A Microsoft anunciou, em um post do time de ADO, que não vai mais desenvolver seu provider de ADO.Net para Oracle. A última versão é a que sai agora no .Net 4.0, e todas as classes estarão marcadas como obsoletas. No .Net vNext, todo o provider não vai mais existir no BCL.

A Oracle faz o próprio provider dela, o ODP.Net, e ele é gratuito e funciona bem. Em diversos pontos é melhor que o da Microsoft, em outros pior.

A Microsoft não anunciou, e pelo que vejo, nunca vai anunciar, um provider para Entity Framework para o Oracle.

O que isso tudo significa?

Na minha visão isso significa que a Microsoft aprendeu, já quando lançou o EF1, que não deve fazer o trabalho de outras empresas, incluindo aí o da concorrente Oracle. As empresas querem um provider para Oracle para o ADO.Net ou para o EF, que pressionem a Oracle para que entregue um.

Exigir da MS que faça um provider de Oracle para o ADO.Net é como exigir que ela faça um player de Flash para o IE, e não a Adobe, ou uma VM de Java para o Windows, e não a Sun (ou qualquer outra empresa que implemente as especificações do Java). No caso, ela até fazia uma JVM própria, mas parou com isso. Agora foi a vez do provider do Oracle.

O que eu acho disso tudo?

Acho mais do que certo. Primeiro porque não é do interesse de uma empresa ficar fazendo software para suportar aplicações de outras empresas. Segundo porque o time de ADO vai estar livre para investir mais no ADO. Terceiro porque libera a Microsoft de ter que ficar polindo um produto que pode ter bugs, e os bugs muitas vezes nem são seus, ou nem deviam estar sob responsabilidade dela para começar. Quarto porque a Microsoft dá claros sinais de fortalecimento ao ecossistema de parceiros quando faz esse tipo de coisa, já que algum parceiro poderá implementar o provider. E quinto, a Microsoft para de reinventar a roda, assumindo que o que há no mercado é bom o suficiente, e por isso ela não tem que ter a versão dela da tecnologia xyz.

(Esse quinto motivo é meio complicado. Muitas empresas não usam software se não for marcado a ferro com a marca Microsoft. É o caso de componentes de Mock, onde a Microsoft não possui uma alternativa. Muita empresa não usa porque a Microsoft não incentiva oficialmente – descontado o P&P, não fomenta o uso, já que não tem um produto para atender.)

Eu sei que algumas empresas vão sofrer, porque utilizam o provider da Microsoft. Então fica aqui a recomendação: se você usa, pare de usar já. Comece a migrar para o ODP.Net ou para outras alternativas, praticamente todas pagas (o lado bom é que algumas suportam EF). Quem começar a pensar nisso agora tem uns bons anos pela frente, já que a Microsoft ainda nem deve ter entrado em fase de concepção do .Net vNext.

Além do mais, código legado vai continuar funcionando e compilando. O único problema será quando você converter uma solução de .Net 4 ou inferior para o .Net vNext. Nesse caso, você vai ter que substituir o provider. Ainda que o ADO.Net abstraia todo o conceito de objetos concretos, eu pouquíssimas vezes vi alguém usando um DbCommand no lugar de um OracleCommand. Dá-lhe mão de obra para arrumar isso.

Aproveitando o problema que esse tipo de coisa vai gerar, deixo aqui algo para reflexão: se você sofrerá com isso, lembre-se que não teria tido problema se adotasse um ORM (se possível). Quem sabe não é a hora?

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.