Entity Framework VS LINQ para SQL VS ADO.NET com procedimentos armazenados? [fechadas]

430

Como você classificaria cada um deles em termos de:

atuação
Velocidade de desenvolvimento
Código puro, intuitivo e sustentável
Flexibilidade
No geral

Eu gosto do meu SQL e, portanto, sempre fui um fã obstinado do ADO.NET e dos procedimentos armazenados, mas recentemente brinquei com o Linq to SQL e fiquei impressionado com a rapidez com que escrevi minha camada do DataAccess e decidi gastar algum tempo realmente entendendo Linq to SQL ou EF ... ou nenhum?

Eu só quero verificar se não há uma grande falha em nenhuma dessas tecnologias que tornaria inútil o meu tempo de pesquisa. Por exemplo, o desempenho é terrível, é legal para aplicativos simples, mas só pode levá-lo tão longe.

Atualização: Você pode se concentrar em EF VS L2S VS SPs em vez de ORM VS SPs. Estou interessado principalmente por EF VS L2S. Mas também quero compará-los com os procs armazenados, pois o SQl simples é algo que eu sei muito sobre.

— BritishDeveloper
fonte

94

não construtivo e ainda assim muitos upvotes? ...;)

— BritishDeveloper 20/09/12

34

Não vejo por que alguém marcou isso como não construtivo. Parece muito bom para mim. +1 de mim.

— Thanushka 18/07/2013

10

Esta é uma excelente pergunta em minha opinião. Pessoalmente, notei o Entity Framework e todos os ORMs similares por aí mais lentamente em comparação com o código ADO.Net simples / simples. Eu fiz esse teste há 2 anos e depois novamente uma semana atrás. Não tenho certeza sobre como o LINQ to SQL se compara ao EF. Mas o ADO.Net sempre será o melhor em desempenho. Se você deseja economizar tempo de desenvolvimento, o Entity Framework é uma boa ferramenta, mas definitivamente não é quando o desempenho é sua principal preocupação.

— Sunil

2

@ Timeless: Há uma tendência de não depender de mecanismos de banco de dados. Todo mecanismo de banco de dados possui sua própria linguagem de procedimentos armazenados, para que haja aprendizado adicional. 99,9% dos desenvolvedores podem confiar nos ORMs, que produzem códigos muito bons e criam SQL automaticamente. A diferença de desempenho é marginal no caso de CRUD simples. Os procedimentos armazenados são mais difíceis de desenvolver e manter. Alguns anos atrás, quando não havia ORMs e nada era gerado de forma mágica e automática do banco de dados. A gravação de SPs foi considerada não demorada, pois era alternativa à gravação de instruções SQL no aplicativo.

— precisa saber é o seguinte

4

@ Sunil está correto, embora não seja suficiente o suficiente. O problema é que todos acham que sua principal preocupação é o desempenho do aplicativo. Quando falo sobre aplicativos que exigem desempenho superior, penso em transações de banco de dados de alto volume com MMO C ++ ou de alto volume voltadas para o cliente. Você realmente deve se concentrar em princípios orientados a objetos, como capacidade de manutenção , legibilidade , ignorância da persistência e separação da lógica do domínio . Especialmente quando o aumento de desempenho é mínimo ou inexistente em muitos casos.

— Suamere

430

Primeiro, se você estiver iniciando um novo projeto, vá com o Entity Framework ("EF") - agora ele gera SQL muito melhor (mais como o Linq to SQL) e é mais fácil de manter e mais poderoso que o Linq to SQL (" L2S "). Desde o lançamento do .NET 4.0, considero o Linq to SQL uma tecnologia obsoleta. A MS tem sido muito aberta quanto a não continuar o desenvolvimento do L2S.

1) Desempenho

Isso é difícil de responder. Para a maioria das operações de entidade única ( CRUD ), você encontrará desempenho equivalente nas três tecnologias. Você precisa saber como o EF e o Linq to SQL funcionam para usá-los ao máximo. Para operações de alto volume, como consultas de sondagem, convém que o EF / L2S "compile" sua consulta de entidade para que a estrutura não precise regenerar constantemente o SQL, ou você pode enfrentar problemas de escalabilidade. (veja edições)

Para atualizações em massa nas quais você está atualizando grandes quantidades de dados, o SQL bruto ou um procedimento armazenado sempre terá um desempenho melhor do que uma solução ORM, porque você não precisa reunir os dados por cabo para o ORM para realizar atualizações.

2) Velocidade de desenvolvimento

Na maioria dos cenários, o EF afasta os processos armazenados / SQL nus quando se trata da velocidade do desenvolvimento. O designer da EF pode atualizar seu modelo do banco de dados à medida que ele muda (mediante solicitação), para que você não tenha problemas de sincronização entre o código do objeto e o código do banco de dados. A única vez em que eu não consideraria o uso de um ORM é quando você está executando um aplicativo do tipo relatório / painel em que não está fazendo nenhuma atualização ou quando está criando um aplicativo apenas para realizar operações de manutenção de dados brutos em um banco de dados.

3) Código puro / de manutenção

De mãos dadas, a EF supera SQL / sprocs. Como seus relacionamentos são modelados, as junções no seu código são relativamente raras. Os relacionamentos das entidades são quase evidentes para o leitor na maioria das consultas. Nada é pior do que ter que passar de depuração de camada para camada ou através de múltiplos SQL / camadas intermediárias para entender o que realmente está acontecendo com seus dados. A EF traz seu modelo de dados para o seu código de uma maneira muito poderosa.

4) Flexibilidade

Os procs armazenados e o SQL bruto são mais "flexíveis". Você pode aproveitar sprocs e SQL para gerar consultas mais rápidas para casos específicos ímpares, além de aproveitar a funcionalidade do banco de dados nativo mais facilmente do que com o ORM.

5) geral

Não fique preso à falsa dicotomia de escolher um ORM vs usar procedimentos armazenados. Você pode usar os dois no mesmo aplicativo e provavelmente deveria. As grandes operações em massa devem ser realizadas em procedimentos armazenados ou SQL (que podem realmente ser chamados pelo EF), e o EF deve ser usado para suas operações CRUD e para a maioria das necessidades da camada intermediária. Talvez você opte por usar o SQL para escrever seus relatórios. Eu acho que a moral da história é a mesma de sempre. Use a ferramenta certa para o trabalho. Mas o mais fino é que a EF é muito boa hoje em dia (a partir do .NET 4.0). Passe algum tempo lendo e entendendo isso em profundidade e poderá criar aplicativos incríveis de alto desempenho com facilidade.

EDIT : O EF 5 simplifica um pouco essa parte com as consultas LINQ compiladas automaticamente , mas para itens de alto volume, você definitivamente precisará testar e analisar o que melhor se adapta a você no mundo real.

— Dave Markle
fonte

35

Resposta absolutamente brilhante. Agora estou realmente usando o EF para desenvolver rapidamente um aplicativo. Se o desempenho se tornar um problema, os procs armazenados serão trazidos para refatorar as consultas EF com desempenho ruim. Obrigado!

— BritishDeveloper

17

@BritishDeveloper: Além disso, não esqueça o poder de usar visualizações também. Tivemos grande sucesso ao definir algumas visualizações em nossos projetos L2S e aproveitá-las onde a estrutura parece escrever consultas ruins. Dessa forma, obtemos todos os benefícios de usar a estrutura com todos os benefícios de escrever nosso próprio SQL.

— Dave Markle

5

Também estou usando o Views;) Mais como uma solução alternativa para a limitação não-db cruzada do EF. Boa idéia para uso para otimização. Obrigado

— BritishDeveloper

5

Definitivamente, uma ótima resposta. Só queria adicionar uma observação que tive em minha própria experiência com L2S vs EF4. Trocado de L2S -> EF4 depois que percebemos que podemos estar usando vários RDMBS differnet ... mas, enquanto ainda executava o MSSQL, a queda de desempenho foi mostrada principalmente na área da GUI do meu aplicativo. A ligação de dados ao conjunto de resultados no L2S foi muito mais rápida que o EF4. É exatamente a mesma consulta no mesmo banco de dados. Uma coisa a notar aqui é que eu estou retornando mais de 90k + discos, então a diferença era bastante óbvia. Talvez em conjuntos menores não seja um problema? Não tenho certeza como seria escalar embora com sites de alta vol ...

— bbqchickenrobot

5

Boa resposta. Passei apenas 4 semanas trabalhando com o LINQ-to-Entities, tentando incluir tudo nele, antes de finalmente perceber que você precisa de SQL nativo para coisas como cópia em massa, exclusão em massa, remoção ultrarrápida de duplicatas de um banco de dados etc. ferramenta certa para o trabalho, não há vergonha em misturar SQL nativo com a estrutura LINQ to Entities.

— Contango

93

Procedimentos armazenados:

(+)

Grande flexibilidade
Controle total sobre SQL
O mais alto desempenho disponível

(-)

Requer conhecimento de SQL
Procedimentos armazenados estão fora do controle de origem
Quantia substancial de "repetir a si mesmo" ao especificar os mesmos nomes de tabela e campo. A alta chance de quebrar o aplicativo após renomear uma entidade do banco de dados e perder algumas referências a ele em algum lugar.
Desenvolvimento lento

ORM:

(+)

Desenvolvimento rápido
Código de acesso a dados agora sob controle de origem
Você está isolado das alterações no banco de dados. Se isso acontecer, você só precisará atualizar seu modelo / mapeamento em um só lugar.

(-)

O desempenho pode ser pior
Pouco ou nenhum controle sobre SQL produzido pelo ORM (pode ser ineficiente ou pior, com bugs). Pode ser necessário intervir e substituí-lo por procedimentos armazenados personalizados. Isso tornará seu código confuso (alguns LINQ no código, alguns SQL no código e / ou no controle de banco de dados fora de origem).
Como qualquer abstração pode produzir desenvolvedores de "alto nível", sem ter idéia de como funciona sob o capô

A troca geral é entre ter uma grande flexibilidade e perder muito tempo versus ficar restrito ao que você pode fazer, mas fazê-lo muito rapidamente.

Não há resposta geral para essa pergunta. É uma questão de guerras sagradas. Também depende de um projeto em mãos e de suas necessidades. Escolha o que funciona melhor para você.

— AGuyCalledGerald
fonte

47

Não acho que os pontos sobre o controle de origem sejam relevantes. O esquema do banco de dados, procedimentos armazenados, UDFs etc podem estar e devem estar sob controle de origem.

— Lee Gunn

15

+1 paraAs any abstraction can produce "high-level" developers having no idea how it works under the hood

— nawfal 12/12/12

3

Concordado, o argumento de controle de origem está incorreto. Sempre armazenamos nossos scripts de criação de banco de dados no svn. Como você pode manter o banco de dados fora do controle de origem ao desenvolver um aplicativo de banco de dados?

— Wout

3

A EF não é realmente adequada para alta disponibilidade e alto desempenho, eu não sou do tipo DBA, mas não vejo o que a EF oferece, o que facilita a codificação.

— Jamie

4

Portanto, estamos renunciando à flexibilidade, controle total e desempenho para "desenvolvimento rápido" e evitando alterações de código se o banco de dados for alterado. Parece pura preguiça para mim.

— user2966445

18

sua pergunta é basicamente O / RM vs mão escrevendo SQL

Usando um ORM ou SQL simples?

Dê uma olhada em algumas das outras soluções de O / RM disponíveis, o L2S não é o único (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

para abordar questões específicas:

Depende da qualidade da solução de O / RM, o L2S é muito bom em gerar SQL
Normalmente, isso é muito mais rápido usando um O / RM quando você grok o processo
O código também é geralmente muito mais limpo e mais sustentável
É claro que o SQL direto oferece mais flexibilidade, mas a maioria dos O / RMs pode fazer todas as consultas, exceto as mais complicadas.
No geral, eu sugeriria usar um O / RM, a perda de flexibilidade é insignificante

— Gelo preto
fonte

@ David Obrigado, mas não é ORM vs SQL. Eu estou olhando para mover-se para ORM e estou querendo saber qual a investir tempo em aprender: EF ou L2S (a menos que eles são lixo em comparação com Stored Procs)

— BritishDeveloper

1

Definitivamente, eu diria que eles não são lixo em comparação com procs armazenados, e um benefício adicional é que você não tem código espalhado no banco de dados. Pessoalmente, eu gosto do L2S, mas ainda não fiz muito com a EF, e parece que o L2EF vai substituí-lo, então eu usaria o EF. Além disso, uma vez que você for para o Linq, você não voltará.

— BlackICE

13

O LINQ-to-SQL é uma peça notável de tecnologia que é muito simples de usar e, em geral, gera consultas muito boas para o back-end. O LINQ para EF foi programado para substituí-lo, mas historicamente tem sido extremamente desajeitado de usar e gerou SQL muito inferior. Não sei o estado atual das coisas, mas a Microsoft prometeu migrar toda a bondade do L2S para o L2EF, então talvez esteja tudo melhor agora.

Pessoalmente, tenho uma aversão apaixonada pelas ferramentas ORM (veja minha descrição aqui para obter detalhes) e, portanto, não vejo razão para favorecer o L2EF, pois o L2S me dá tudo o que espero de uma camada de acesso a dados. De fato, acho que recursos do L2S, como mapeamentos artesanais e modelagem de herança, adicionam complexidade completamente desnecessária. Mas sou só eu. ;-)

— Marcelo Cantos
fonte

1

O L2S é muito bom, mas tem a desvantagem de que a Microsoft afirmou que basicamente não vai investir muito em estendê-lo. Você pode ver os resultados disso já na versão mais recente, que possui apenas algumas correções de bugs e suporte para os tipos de dados do SQL Server 2008 adicionados.

— FinnNk

De acordo, @FinnNk. É uma realidade infeliz que o uso do L2S seja um pouco arriscado devido ao seu status de pária. Mas se eles realmente se interessaram completamente pelo L2EF, suspeito fortemente que haveria um caminho de migração, devido ao seguinte: ele ainda desfruta.

— Marcelo Cantos

3

O Linq to EF amadureceu e agora produz SQL tão bom quanto L2S (a partir do .NET 4.0). Atualmente, o L2EF é muito melhor do que o L2S, pois pelo menos pode atualizar seu modelo conforme o DB muda, o que o L2S nunca poderia fazer automaticamente. Também gosto do fato de que você pode mapear relacionamentos M: M simples com EF como relacionamentos sem precisar ter uma entidade intermediária. Isso torna o código muito mais limpo.

— Dave Markle

2

Obrigado pela atualização @Dave. Mas eu discordo do comentário M: M. Os esquemas com os quais trabalhei quase sempre aumentam atributos extras nas tabelas de junção. Isso induz uma alteração estrutural no modelo de objeto, exigindo muito retrabalho de código. Prefiro lidar com a relação intermediária explicitamente desde o início.

— Marcelo Cantos

1

Há uma abordagem totalmente nova que você pode considerar se procura o poder e o desempenho dos procedimentos armazenados e o rápido desenvolvimento que ferramentas como o Entity Framework fornecem.

Eu levei o SQL + para um test drive em um projeto pequeno, e é realmente algo especial. Basicamente, você adiciona o que equivale a comentários às suas rotinas SQL e esses comentários fornecem instruções para um gerador de código, que cria uma biblioteca de classes orientada a objetos muito boa, com base na rotina SQL real. Tipo de estrutura de entidade semelhante ao contrário.

Os parâmetros de entrada se tornam parte de um objeto de entrada, os parâmetros de saída e os conjuntos de resultados se tornam parte de um objeto de saída, e um componente de serviço fornece as chamadas de método.

Se você deseja usar procedimentos armazenados, mas ainda deseja um desenvolvimento rápido, pode dar uma olhada nessas coisas.

— Vincent
fonte