Por que você deve usar um ORM? [fechadas]

Se você fosse motivar os "prós" de por que você usaria um ORM para gerenciamento / cliente, quais seriam os motivos?

Tente manter um motivo por resposta para que possamos ver o que foi votado como os melhores motivos

Tornando o acesso aos dados mais abstrato e portátil. As classes de implementação ORM sabem como escrever SQL específico do fornecedor, então você não precisa.

A razão mais importante para usar um ORM é para que você possa ter um modelo de negócios rico e orientado a objetos e ainda ser capaz de armazená-lo e escrever consultas eficazes rapidamente em um banco de dados relacional. Do meu ponto de vista, não vejo nenhuma vantagem real que um bom ORM oferece quando comparado com outros DALs gerados além dos tipos avançados de consultas que você pode escrever.

Um tipo de consulta em que estou pensando é uma consulta polimórfica. Uma consulta ORM simples pode selecionar todas as formas em seu banco de dados. Você recebe uma coleção de formas de volta. Mas cada instância é um quadrado, círculo ou retângulo de acordo com seu discriminador.

Outro tipo de consulta seria aquela que busca avidamente um objeto e um ou mais objetos ou coleções relacionados em uma única chamada de banco de dados. Por exemplo, cada objeto de forma é retornado com seu vértice e coleções laterais preenchidas.

Lamento discordar de tantos outros aqui, mas não acho que a geração de código seja uma razão boa o suficiente por si só para ir com um ORM. Você pode escrever ou encontrar muitos modelos DAL bons para geradores de código que não têm a sobrecarga conceitual ou de desempenho que os ORMs têm.

Ou, se você acha que não precisa saber escrever um bom SQL para usar um ORM, novamente, eu discordo. Pode ser verdade que, da perspectiva de escrever consultas únicas, confiar em um ORM é mais fácil. Mas, com ORMs, é muito fácil criar rotinas de baixo desempenho quando os desenvolvedores não entendem como suas consultas funcionam com o ORM e o SQL em que se traduzem.

Ter uma camada de dados que funciona em vários bancos de dados pode ser uma vantagem. Porém, não é algo em que eu tenha que confiar muito.

No final, devo reiterar que, em minha experiência, se você não estiver usando os recursos de consulta mais avançados do seu ORM, existem outras opções que resolvem os problemas restantes com menos aprendizado e menos ciclos de CPU.

Sim, alguns desenvolvedores acham divertido trabalhar com ORMs, portanto, ORMs também são bons do ponto de vista de manter seus desenvolvedores felizes. =)

Acelerando o desenvolvimento. Por exemplo, eliminar o código repetitivo, como mapear os campos de resultados da consulta para membros do objeto e vice-versa.

Apoiar o encapsulamento OO de regras de negócios em sua camada de acesso a dados. Você pode escrever (e depurar) regras de negócios no idioma de preferência do aplicativo, em vez de gatilhos desajeitados e linguagens de procedimento armazenado.

Gerando código clichê para operações CRUD básicas. Algumas estruturas ORM podem inspecionar metadados de banco de dados diretamente, ler arquivos de mapeamento de metadados ou usar propriedades de classe declarativas.

Você pode mudar para um software de banco de dados diferente facilmente porque está desenvolvendo para uma abstração.

Para que seu modelo de objeto e modelo de persistência correspondam.

Felicidade de desenvolvimento, IMO. O ORM abstrai muitas das coisas bare-metal que você precisa fazer no SQL. Ele mantém sua base de código simples: menos arquivos de origem para gerenciar e as alterações de esquema não requerem horas de manutenção.

Atualmente, estou usando um ORM e ele acelerou meu desenvolvimento.

Para minimizar a duplicação de consultas SQL simples.

O motivo pelo qual estou pesquisando é para evitar o código gerado pelas ferramentas DAL do VS2005 (mapeamento de esquema, TableAdapters).

O DAL / BLL que criei há mais de um ano estava funcionando bem (para o que eu o havia criado) até que outra pessoa começou a usá-lo para tirar proveito de algumas das funções geradas (que eu não tinha ideia que existiam)

Parece que fornecerá uma solução muito mais intuitiva e limpa do que a solução DAL / BLL de http://wwww.asp.net

Eu estava pensando em criar meu próprio gerador de código SQL Command C # DAL, mas o ORM parece uma solução mais elegante

Compilação e teste de consultas.

À medida que as ferramentas para ORM são aprimoradas, é mais fácil determinar a exatidão de suas consultas mais rapidamente por meio de erros e testes de tempo de compilação.

Compilar suas consultas ajuda os desenvolvedores a encontrar erros mais rapidamente. Certo? Certo. Essa compilação é possível porque os desenvolvedores agora estão escrevendo consultas em código usando seus objetos ou modelos de negócios, em vez de apenas strings de SQL ou instruções semelhantes a SQL.

Se estiver usando os padrões de acesso a dados corretos no .NET, é fácil testar a unidade de sua lógica de consulta em coleções de memória. Isso acelera a execução de seus testes porque você não precisa acessar o banco de dados, configurar dados no banco de dados ou até mesmo girar um contexto de dados completo. [EDITAR] Isso não é tão verdade quanto eu pensava que era como unidade o teste de memória pode apresentar desafios difíceis de superar. Mas eu ainda acho esses testes de integração mais fáceis de escrever do que nos anos anteriores. [/ EDIT]

Isso é definitivamente mais relevante hoje do que alguns anos atrás, quando a pergunta foi feita, mas pode ser o caso apenas do Visual Studio e do Entity Framework, onde está minha experiência. Conecte seu próprio ambiente, se possível.

Abstraia o sql 95% do tempo, portanto, nem todos na equipe precisam saber como escrever consultas supereficientes para um banco de dados específico.

Acho que há muitos pontos positivos aqui (portabilidade, facilidade de desenvolvimento / manutenção, foco na modelagem de negócios OO etc), mas ao tentar convencer seu cliente ou gerenciamento, tudo se resume a quanto dinheiro você economizará usando um ORM .

Faça algumas estimativas para tarefas típicas (ou mesmo projetos maiores que possam estar surgindo) e você (com sorte!) Obterá alguns argumentos difíceis de ignorar para alternar.

Camadas .net usando modelos de código smith

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Por que codificar algo que também pode ser gerado.

convencê-los de quanto tempo / dinheiro você vai economizar quando as mudanças chegarem e você não tiver que reescrever seu SQL já que a ferramenta ORM fará isso por você

Acho que um dos contras é que o ORM precisará de alguma atualização em seu POJO. principalmente relacionado a esquema, relação e consulta. portanto, o cenário em que você não deve fazer alterações nos objetos do modelo pode ser porque ele é compartilhado entre mais do que no projeto ou cliente e servidor p / b. então, nesses casos, você precisará dividi-lo em dois níveis, o que exigirá esforços adicionais.

Eu sou um desenvolvedor Android e, como você sabe, os aplicativos móveis geralmente não são enormes em tamanho, então este esforço adicional para separar o modelo puro do modelo afetado por orm não parece valer a pena.

eu entendo que a pergunta é genérica. mas os aplicativos móveis também estão dentro de um guarda-chuva genérico.