Quais são alguns argumentos contra o uso de EntityFramework? [fechadas]

31

O aplicativo que estou construindo atualmente usa procedimentos armazenados e modelos de classe criados manualmente para representar objetos de banco de dados. Algumas pessoas sugeriram o uso do Entity Framework e estou pensando em mudar para isso, já que não estou muito longe no projeto. Meu problema é que sinto que as pessoas que defendem a EF estão apenas me dizendo o lado bom das coisas, não o lado ruim :)

Minhas principais preocupações são:

Queremos a validação do lado do cliente usando o DataAnnotations, e parece que eu tenho que criar os modelos do lado do cliente de qualquer maneira, então não tenho certeza de que o EF economizaria tanto tempo de codificação
Gostaríamos de manter as classes o menor possível ao passar pela rede, e eu li que o uso do EF geralmente inclui dados extras que não são necessários
Temos uma camada de banco de dados complexa que atravessa vários bancos de dados, e não tenho certeza de que a EF possa lidar com isso. Temos um banco de dados comum com usuários, códigos de status, tipos etc. e várias instâncias de nossos principais bancos de dados para diferentes instâncias do aplicativo. As consultas SELECT podem e farão consultas em todas as instâncias dos bancos de dados, no entanto, os usuários podem modificar apenas objetos que estão no banco de dados em que estão trabalhando no momento. Eles podem alternar bancos de dados sem recarregar o aplicativo.
Os modos de objeto são muito complexos e muitas vezes há muitas junções envolvidas

Os argumentos para EF são:

Concorrência. Não precisaria codificar as verificações para ver se o registro foi atualizado antes de cada salvamento
Geração de código. A EF pode gerar modelos de classe parciais e POCOs para mim, no entanto, não tenho certeza de que isso me pouparia muito tempo, pois acho que ainda precisaríamos criar modelos do lado do cliente para validação e alguns métodos de análise personalizados.
Velocidade de desenvolvimento, pois não precisamos criar os procedimentos armazenados CRUD para cada objeto de banco de dados

Nossa arquitetura atual consiste em um serviço WPF que lida com chamadas de banco de dados por meio de procedimentos armazenados parametrizados, objetos POCO que vão para / do serviço WCF e do cliente WPF e o próprio cliente de desktop WPF que transforma os POCOs em modelos de classe para fins de validação e Ligação de dados.

Então, minha pergunta é: a EF está certa para isso? Existem armadilhas sobre a EF que eu desconheço?

architecture orm entity-framework

— Rachel
fonte

Confira isso também .. uma comparação de desempenho e suporte a LINQ: ormeter.net

— M.Sameer

7

Recentemente, eu estava avaliando o Entity Framework e o melhor local que encontrei para problemas e recursos ausentes foi: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Os itens com mais votos:

Suporte para enums. Este é bem grande, mas atualmente existem algumas soluções alternativas
Geração SQL aprimorada. A velocidade é realmente importante, especialmente para aplicativos de nível corporativo, mas parece que com o EF4 melhorou bastante
Suporte para vários bancos de dados. Requisito para qualquer aplicação grande.

Existem muitos outros problemas na lista Voz do usuário.

Em uma nota lateral, estou bastante animado com o lançamento do EF 4.1, que incluirá a abordagem Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidate-available.aspx

Isso pode me levar a experimentar o EF em um aplicativo de produção.

— Mag20
fonte

Argumento contra: 1º e 2º e 3º: É LENTO !!! Há uma curva de aprendizado (é necessário saber como fazer uma junção esquerda - leva 3 horas para descobrir uma maneira de fazê-lo, para que outra pessoa saiba o que está sendo feito ...), paginando no LINQ em vez de SQL (por exemplo, feches 10 milhões de linhas e, em seguida, obtém 20 delas de um deslocamento arbitrário, e então você se pergunta por que é tão lento) ... O repositório é seguro para não-passo, você precisa iniciá-lo por consulta e a inicialização do repositório é MUITO LENTO (como 5 segundos) se você tiver um banco de dados maior (isso significa 100-200 tabelas, não REALMENTE REALMENTE grande).

— Quandary

2

@ Quandary Parece que você está executando IQueryables (ou seja, chamando .ToList()ou .ToArray) antes que suas expressões LINQ sejam totalmente definidas. É por isso que ele puxa todos os registros e o torna lento.

— orad 27/07/16

6

Fazer ramificação por bug / recurso com EF pode ser notavelmente doloroso no momento da mesclagem. Imagine que duas ramificações A e B façam alterações no banco de dados (o que provavelmente acontecerá muito durante os estágios iniciais de um novo projeto).

Você mescla todos os arquivos "normais" - arquivos cs, etc. E então é hora de mesclar Model.edmx. E de repente você não está apenas mesclando os mapeamentos lógicos entre seu modelo de objeto e banco de dados, mas também as posições das tabelas no diagrama de entidades.

Mesclar Model.edmx é tão doloroso que adotamos uma maneira bastante desagradável que funciona:

Durante a mesclagem, basta selecionar todas as mesclagens de um pai. O que não importa; você brindará o arquivo em breve assim mesmo:
Reverta Model.edmx para um dos pais.
Migre seu banco de dados para o novo estado mesclado.
Abra o Model.edmx e "Atualizar modelo do banco de dados".
Renomeie todas as propriedades de navegação exibidas durante a mesclagem.

— Frank Shearar
fonte

1

Essa crítica não é válida para o EF Code First, mas se aplica ao Model First e Database First.

— Alan Macdonald

Eu mesmo crio todos os mapeamentos usando o Fluent e assumo o controle total do mapeamento. Eles são colocados dentro de um arquivo .cs separado.

— Steven Ryssaert 5/02

5

Existem alguns outros benefícios para a EF:

Você pode ter tabelas de extensão de entidade
Você pode dividir uma tabela em vários tipos de entidades
Você pode gerar as entidades a partir do banco de dados (ou seja, banco de dados como abordagem principal)
Você pode gerar o banco de dados a partir de entidades (ou seja, código como abordagem principal)
As consultas LINQ são convertidas em consultas SQL, melhorando seu desempenho.

As desvantagens (principalmente se você estiver usando a validação):

Você deve criar um atributo [MetadataClass] que aponte para outra classe que possua as propriedades que você deseja validar com os atributos de validação apropriados. Todas as propriedades são objecttipos, portanto, basta ler os metadados. Ainda há muito código inativo extra.
Usar EntityFramework é um conceito diferente do que a maneira como algo como NHibernate (e a versão Java pai também) é projetado para funcionar. O EntityFramework funciona melhor no modo anexado , em que os objetos estão sempre usando uma conexão ao vivo. As ferramentas NHibernate e ORM similares funcionam melhor no modo desanexado , em que a conexão é usada apenas ao carregar / salvar dados.

Essas são as duas maiores reclamações que tenho. Há vários benefícios, mas você pode obter esses mesmos benefícios do NHibernate. Se o EntityFramework estiver em cima da mesa, peça à equipe que verifique o NHibernate e faça uma rápida busca dos prós / contras do seu projeto.

O problema da classe de metadados é uma dor de cabeça, mas felizmente só tenho tantas entidades que precisam de tags de validação.

A falta de um verdadeiro modo desanexado para seus objetos limita o que você pode fazer em um ambiente da web. O modo anexado é melhor para aplicativos de desktop, que é onde se originaram várias inovações da Microsoft. O modo desanexado é possível , mas muito doloroso. É melhor usar uma ferramenta alternativa neste caso.

— Berin Loritsch
fonte

Seu assim chamado código como mestre abordagem é oficialmente chamado de código primeiro

— Robert Koritnik

1

@ Berin, quero esclarecer o que você quer dizer com "modo anexado". Eu não acho que o Entity Framework tenha uma conexão com o banco de dados aberto o tempo todo. Acredito que a EF funcione de maneira semelhante ao NHibernate a esse respeito. É isso o que você quer dizer ou quer dizer outra coisa? Você tem um link para a documentação que explica esse problema em anexo?

— RationalGeek

1

Em anexo, quero dizer que todas as suas interações com os objetos devem ocorrer dentro da using(EFConnection conn = new EFConnection)construção. Se você tentar esconder esse objeto em algum lugar para mantê-lo seguro, para poder fazer uma atualização rápida e salvá-lo novamente em uma segunda using(...)declaração, precisará pensar novamente. Consulte msdn.microsoft.com/en-us/library/bb896271.aspx e msdn.microsoft.com/en-us/library/bb896248.aspx . Usar o EF 3.5 (que eu tive que usar na última versão) não é tão limpo assim.

— Berin Loritsch 16/03

Ok, entendi o que você quer dizer agora. Eu só queria garantir que as pessoas não entendessem isso, pois sempre havia uma conexão com o banco de dados . Você precisa ter um contexto de objeto que mantenha o estado das entidades "anexadas".

— RationalGeek

2

Isso não é verdade. A EF tem uma forte noção de entidades independentes. Uma entidade desanexada deve ser reconectada ao seu contexto antes que você possa executar operações relacionadas ao contexto (como atualizá-la no banco de dados). Além disso, as classes de metadados são necessárias apenas se o EF gerar suas entidades para você. Os POCOs, IMO, são uma maneira muito melhor de usar o EF. O uso de POCOs torna muitas coisas muito mais simples, principalmente testes.

— Matt Greer

2

Uma coisa na qual a Microsoft não é muito boa é a compatibilidade com ~~comparabilidade~~ reversa, especialmente quando se trata de novas tecnologias

Especificamente, EF1 (.net 3.5) é muito diferente de EF4 (.net 4.0) - o mesmo pode ocorrer na próxima versão.

Eu esperaria um pouco e veria como a tecnologia amadurece.

Enquanto isso, considere usar o nHibernate - não é equivalente, mas é maduro e amplamente utilizado.

— Ophir Yoktan
fonte

1

Simplesmente ... o Modelo de Domínio raramente é uma réplica do modelo relacional no seu banco de dados. Portanto, mapear algumas tabelas para uma classe e jogá-las pelo arame é simplesmente preguiça. As tabelas podem mapear localmente em 1 objeto, mesmo que o banco de dados possua três tabelas diferentes. Projete o banco de dados de maneira inteligente.
Segundo, esse material EF não pode gerar determinadas consultas e você precisará escrevê-las de qualquer maneira.
3º O Modelo de Domínio não é mapeado diretamente para os serviços. Só será necessário enviar o conjunto de dados mais mínimo possível como DTOs. Especialmente se ele estiver se comunicando com aplicativos móveis.
5ª capacidade de teste ... Não é possível criar testes granulares suficientes que fornecerão regressão suficiente contra alterações de código ... tudo fácil de
quebrar ...

Eu poderia escrever uma diatribe de 10 páginas. Mas, se você está apenas escrevendo um aplicativo para a Empresa X .. quem se importa então. Mas, se você estiver desenvolvendo um produto de software ... terá que ser muito mais anal

— user104468
fonte

é difícil ler este post (parede de texto). Você se importaria de editá -lo em uma forma melhor?

— Gnat #

O EF não gera objetos de domínio. Esses são DAO. Você precisará usar os dados do objeto para criar seu objeto de domínio. Você não deve enviar objetos de domínio de volta de um serviço de qualquer maneira; portanto, crie seu DTO mais fino a partir dos objetos de domínio antes de retornar. A EF deve conseguir gerar quase tudo o que você pode expressar no LINQ. O banco de dados não faz parte de um teste de unidade, faz parte de um teste funcional. Dito isto, existem na memória zombarias disponíveis para a EF. Caso contrário, abstraia suas consultas EF para um repositório e, em seguida, simule isso.

— Sinaesthetic

Sim, concordo. Estou me referindo aos padrões estabelecidos por Martin Fowler e Carig Lairman. No final do dia, não posso usar CTEs, PARTITION BY ou CROSS APPLY. Eu também não posso usar um IDataReader que permita manter a sobrecarga de memória baixa. Além disso, quando eu executar o rastreio de SQL e ver o que EF envia através do fio Eu me sinto como se eu pudesse vomitar ;-)

— user104468

0

Verifique isto: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Os pontos principais são:

Falta de carregamento lento
Falta de persistência ignorância
O formato do arquivo usado para salvar o modelo de entidade contém elementos de visualização e o próprio modelo de entidade causa problemas de mesclagem no ambiente de equipe.

Observe que o link acima está falando sobre EF1.

Também este link: http://ormeter.net/ mostra que o EF não é o melhor em comparação com outros ORMs em desempenho e suporte a LINQ.

— M.Sameer
fonte

Lembre-se de que isso foi publicado quando o EF 1 ainda foi lançado recentemente (ou possivelmente ainda está na versão beta). Hoje, a situação está muito melhor com o EF 4 e muitas das questões levantadas nesse voto de desconfiança foram resolvidas.

— RationalGeek

O último ponto ainda conta e é muito significativo.

— M.Sameer

1

A primeira versão da EF foi 3.5. Não foram lançadas quatro versões principais do EF.

— Matt Greer

3

@ Matt está correto. Mas a versão atual é chamada EF 4 para alinhar-se com o restante do versionamento do .NET 4.

— RationalGeek

1

Se é válido ou não, não deve afetar o resumo do link. Os votos serão exibidos se for válido. :)

— Adam Lear