Entity Framework - Suporte para múltiplas BD

Uma das limitações que o EF ainda tem é o seu suporte para múltiplas bases de dados. A opção simplesmente não é suportada à partida, apesar de atrair muitos votos no UserVoice.

Antes de mais, quero dar crédito aos autores da ideia original. Esta ideia não foi minha. Eu fiz download do script original, utilizei-o e depois reescrevi-o quase completamente para lidar com alguns casos adicionais. Eu adoro Linq, por isso aproveitei para utilizar bastante na nova versão. O script original pode ser encontrado aqui.

O truque é fazer o EF acreditar que todas as tabelas/objectos mapeados estão na mesma base de dados utilizando sinónimos. Eu não sei se todas as BD's suportadas pelo EF têm alguma feature semalhante a sinónimos, mas isto é certamente possível no SQL Server (que eu estou actualmente a usar).

O meu script acrescenta a possibilidade de primeiro fazer backup dos ficheiros edmx (algo que eu acho útil para evitar que o meu modelo fique corrompido), substitui os prefixos no modelo resultante (que eu tinha que fazer à mão com o script anterior) e finalmente ordena as navigation properties por ordem alfabética. Esta última opção é muito importante para mim, porque eu uso o LINQPad bastante e as propriedades aparecem como links na ordem em que estão declaradas no modelo. Outra mudança inclui a possibilidade de importar os Function Imports declarados (se não estou enganado, o script original dava um erro pela falta de um atributo no elemento FunctionImport).

Os seguintes procedimentos devem ser executados para que esta abordagem funcione. Eu sei que parece muito, mas o fim justifica o meio:

• Deve ser definida uma base de dados que terá todos os sinónimos para objectos de outras bases de dados. Este é o nosso ponto de entrada no EF, e pode ser qualquer base de dados dentro da mesma instância.

• Devem ser criados sinónimos para cada tabela/view/função das bases de dados secundárias que serão mapeados para o modelo. Eu costumo gerar um script que cria código para gerar sinónimos por todas as tabelas e funções. Algo deste género:

• Deve ser criado um modelo por cada base de dados que queremos utilizar.


• Configuramos as variáveis no script. É necessário configurar o caminho para os modelos, o destino dos backups e o caminho do modelo resultante do merge. Ainda existem semelhanças com o script original na minha versão. Não esquecer de alterar o XNamespace no início do script. Estes podem variar dependendo da versão do EF. 

• Ir ao método ReplacePrefixes e configurar a variável "CorrectPrefix". Esta variável deve conter o nome do Conceptual Model (Modelo Conceptual) do nosso modelo principal, isto é, aquele que criámos para a nossa base de dados principal. Finalmente, configurar as substituições mais abaixo, na linha onde o método Replace(string, string) é chamado.


• Fazer backup manual de tudo primeiro. Podem ocorrer problemas


• Correr o script. Abrir e validar o modelo resultante para verificar se tudo correu bem. Daqui em diante, cada vez que houver actualizações em algum dos modelos periféricos basta repetir este passo e as alterações serão reflectidas no modelo principal.

Limitações

• O script é uma alternativa para quando precisamos deste tipo de feature. É uma pena o EF não suportar isto, porque muitas vezes não é possível começar com uma BD desenhada para este efeito. Dito isto, as Entities não serão removidas do edmx principal forem apagadas de um edmx secundário. Na altura não precisava desta feature, por isso não a implementei.

• Não é possível garantir que este script funcione em todos os casos. O modelo que uso não é extremamente complexo e não dá cobertura a todos os casos de mapping possíveis, por isso podem faltar algumas features. 


• Navigation properties entre entidades de modelos diferentes são suportadas. Certifiquem-se que as nomeiam com o prefixo "LNK_". Isto permite-me manter as relações enquanto faço o merge em vez de as apagar. Esta abordagem é exactamente a mesma que a do script original. Caso prefiram, é possível alterar o prefixo no método MergeEDMX.


• Cuidado com objectos com o mesmo nome entre modelos diferentes. Se existir um conflito, o modelo ficará corrompido e terá de ser alterado manualmente, ou repôr-se os backups. 


• Quando tem que se actualizar o modelo da base de dados, façam-no sempre nos modelos secundários, ou no modelo que representa cada base de dados em separado, e não no modelo construído pelo script.


• Sempre que ocorrer uma mudança num dos modelos secundários, teremos que fazer o merge com o principal. Não é necessário fazer merge de todos os modelos secundários ao mesmo tempo.

Chega de conversa, aqui está o script. Façam bom uso dele!



Nota: Lembrem-se de testar o script antes de o utilizarem. Isto é um workaround e portanto não é perfeito, podendo conter bugs ou comportamento inesperado.