Você deve reutilizar um Entity Framework EDMX entre várias soluções?

5

Atualmente, temos 1 gigante EDMX para nosso banco de dados corporativo. Ele, juntamente com todos os POCOs gerados, estão em um projeto separado (nós o chamaremos de projeto EDMX), o qual nós puxamos para qualquer solução que use o principal base de dados. Em outras palavras, qualquer nova aplicação que desenvolvemos usa esse mesmo projeto EDMX. Naturalmente, o projeto EDMX requer uma referência ao Entity Framework. Mas o mesmo acontece com os principais projetos de cada aplicativo. Assim, uma determinada solução tem duas referências separadas ao Entity Framework - que podem acabar sendo versões completamente diferentes.

Eu herdei esta configuração e agora tenho a oportunidade de fazer algumas grandes mudanças. Eu suspeito que não devemos usar este EDMX para várias soluções, mas não temos 100% de certeza.

Perguntas

  1. Poderia ter duas versões diferentes do Entity Framework em uma determinada solução causando problemas? Parece que seria, e certamente não queremos restringir nossos aplicativos mais recentes a uma versão antiga da EF para trabalhar com o projeto EDMX, que por sua vez funciona com soluções antigas.
  2. Há algum outro motivo para isso ser ruim?



Nota: Li questões semelhantes sobre o uso de 1 EDMX dentro da mesma solução (vs. dividindo por esquema, etc.), mas minha pergunta é diferente porque estou falando sobre o uso de 1 EDMX para todas as soluções .


EDIT 10/16/14: Então eu praticamente tenho a minha primeira pergunta respondida. Pelo menos entre o Entity Framework 5 e o Entity Framework 6, ele realmente causa problemas. Quando meu projeto EDMX tem o EF5 instalado, e eu atualizo meu projeto principal para o EF6, muitas das minhas consultas LINQ (dentro do projeto principal, referenciando as classes POCO geradas dentro do projeto EDMX) são quebradas. Pelo que entendi, isso tem algo a ver com as mudanças no namespace. Se houver uma solução alternativa para fazer as duas versões funcionarem juntas, não a encontrei.

Minha segunda pergunta ainda precisa ser respondida, no entanto. Existem outras razões para isso, além de versões conflitantes do Entity Framework? Do ponto de vista do design, ter 1 EDMX faz sentido? Prós poderia ser facilidade de atualização (se uma tabela de banco de dados usada por vários projetos for alterada, haverá 1 local para atualizá-la). A desvantagem óbvia é que os novos projetos são restritos a uma versão antiga do EF até que todos os outros projetos sejam atualizados. Quaisquer outros problemas que surgem? Realmente apenas procurando por alguma direção.


EDIT 10/17/14 Aceitei uma resposta, mas os comentários sobre o uso do EDMX por você / sua empresa ainda seriam úteis / votados em excesso. Quanto mais perspectiva, melhor.

    
por EF0 10.10.2014 / 20:14
fonte

1 resposta

2

Depende.

A principal coisa que eu gostaria de focar é "não se repita". Se você tem um monte de aplicativos usando as mesmas entidades, não faz sentido gastar um monte de tempo e esforço fazendo e, em seguida, manter a mesma coisa uma e outra vez. Pior, pode se tornar uma dor de cabeça para manter todos eles corretos e em sincronia.

Por outro lado, se você realmente tem vários esquemas diferentes que vivem no mesmo banco de dados (e não interagem), então pode fazer sentido ter vários arquivos EDMX independentes.

Eu vi os dois caminhos e eles funcionaram bem o suficiente em seus ambientes. Mas, dadas as dificuldades do Entity Framework em jogar bem com os outros, eu errei em colocar todo um banco de dados em um único projeto, já que é menos trabalho "apenas usar parte dele" do que "fazer com que outras coisas também" meu palpite está errado sobre o uso futuro.

    
por 16.10.2014 / 18:41
fonte