Migrando Código de Acesso a Dados .NET de Oracle para PostgreSQL

Migre a camada de acesso a dados C# de um projeto de cópia única .Postgres de Oracle (Oracle.ManagedDataAccess) para PostgreSQL (Npgsql). Trabalhe item por item através de Reports/{ProjectName}/MigrationChecklist.md.

Pré-requisitos

• A cópia do projeto .Postgres existe (criada na configuração da Fase 5).
• Reports/{ProjectName}/MigrationChecklist.md existe e é a fonte da verdade para o que mudar.
• Reports/{ProjectName}/OracleRiskAnalysis.md existe para referências cruzadas de diferenças comportamentais.

Fluxo de Trabalho

Progress:
- [ ] Step 1: Replace NuGet packages
- [ ] Step 2: Update connection string configuration
- [ ] Step 3: Rewrite ADO.NET type references
- [ ] Step 4: Fix DbType mappings
- [ ] Step 5: Migrate stored procedure invocation
- [ ] Step 6: Address Oracle-specific SQL and syntax
- [ ] Step 7: Build and verify

Passo 1: Substituir pacotes NuGet

No .csproj do projeto .Postgres:

• Remover: Oracle.ManagedDataAccess.Core, Oracle.EntityFrameworkCore (e quaisquer outros pacotes Oracle.*)
• Adicionar: Npgsql (para ADO.NET) e/ou Npgsql.EntityFrameworkCore.PostgreSQL (para EF Core)
• Mantenha o "pinning" de versão consistente com a versão .NET de destino; não introduza versões de pacotes mais novas do que as que a solução já usa para pacotes semelhantes.
• Se abstrações System.Data (IDbConnection, IDbCommand) forem usadas em todo o projeto, o código de nível superficial pode precisar de menos alterações — identifique-as primeiro.

Passo 2: Atualizar configuração da string de conexão

• Localize a string de conexão Oracle em appsettings.json, appsettings.{env}.json, web.config, app.config ou configuração de variável de ambiente.
• Substitua por uma string de conexão compatível com Npgsql: Host=localhost;Port=5432;Database=mydb;Username=myuser;Password=mypassword
• Não codifique credenciais diretamente — use o mesmo mecanismo de configuração já em uso (por exemplo, variáveis de ambiente, gerenciador de segredos, IConfiguration).
• Atualize quaisquer chaves de string de conexão nomeadas apenas se fossem específicas do Oracle (por exemplo, OracleConnection). Prefira manter o mesmo nome de chave para minimizar as alterações na configuração do aplicativo.

Passo 3: Reescrever referências de tipo ADO.NET

Substitua tipos ADO.NET específicos do Oracle por equivalentes Npgsql:

Atualize as diretivas using de acordo (using Oracle.ManagedDataAccess.Client → using Npgsql).

Se a base de código usar abstrações IDbConnection/IDbCommand registradas via DI, atualize apenas o registro DI e a string de conexão — o código consumidor pode não precisar de alterações.

Passo 4: Corrigir mapeamentos DbType e NpgsqlDbType

Os tipos de parâmetro Oracle não são mapeados 1:1 para Npgsql. Revise cada OracleParameter (agora NpgsqlParameter) que define um tipo explícito:

Para parâmetros onde o Oracle inferiu o tipo do valor, o Npgsql também infere — a definição explícita de tipo geralmente é desnecessária e pode ser removida.

Passo 5: Migrar invocação de stored procedure

A invocação de stored procedure Oracle e PostgreSQL difere significativamente:

• Tipo de comando: Mantenha CommandType.StoredProcedure para chamadas de função. Para procedimentos que usam parâmetros OUT, o PostgreSQL requer CommandType.Text com sintaxe CALL proc_name(...) em algumas versões do Npgsql — verifique em relação à versão Npgsql de destino.
• Tratamento de RefCursor: Oracle retorna ref cursors como parâmetros de saída; PostgreSQL os retorna de forma diferente:
  • Para RETURNS TABLE / RETURNS SETOF, use ExecuteReader() diretamente — nenhum parâmetro de cursor é necessário.

…