ORM é um antipadrão? [fechadas]

Há um conjunto bastante grande e variado de dificuldades conceituais e técnicas ao tentar se aproximar de um banco de dados relacional de um ângulo orientado a objeto. Essas dificuldades são conhecidas coletivamente como incompatibilidade entre impedância objeto-relacional e o artigo da Wikipédia relacionado é extremamente informativo. O artigo identifica muito poucos, não vejo nenhuma maneira sensata de descrevê-los aqui. Só para dar uma ideia geral, eles são catalogados como:

• Mismatches
  • Object-oriented concepts
  • Data type differences
  • Structural and integrity differences
  • Manipulative differences
  • Transactional differences
• Solving impedance mismatch
  • Minimization
  • Alternative architectures
  • Compensation
• Contention
• Philosophical differences

Acho que, se você ler o artigo, você entenderá que o fato de ORM ser às vezes descrito como um antipadrão é, na verdade, inevitável. Os dois domínios são tão diferentes que qualquer abordagem para tratar um como o outro é, por padrão, um antipadrão, no sentido de que um antipadrão é um padrão que vai contra a filosofia de um domínio.

Mas eu não acho que o termo deva se aplicar a qualquer coisa que essencialmente atue como uma ponte entre dois domínios vastamente diferentes. Rotular um padrão como anti-padrão só faz sentido dentro de seu domínio. Então, a questão de saber se é um anti-padrão ou não é irrelevante.

Mas é útil? Sim ORM é um dos anti-padrões mais úteis por aí. Você entenderá por que somente se você se encontrar em uma situação prática onde terá que trocar bancos de dados em um projeto. Ou até mesmo atualizar para outra versão do mesmo banco de dados. O ORM é uma daquelas coisas que você só entende quando realmente precisa delas.

Claro, como tudo é útil, o ORM é altamente propenso ao abuso. Se você acha que isso de alguma forma substitui a necessidade de saber tudo sobre o banco de dados em que você trabalha, então ele vai voltar e morder você. Difícil.

Por fim, deixe-me descaradamente ligar outra das minhas respostas , no relacionado " O padrão ActiveRecord segue / incentiva os princípios de design do SOLID? " pergunta, que para mim é uma questão muito mais relevante do que" é um anti-padrão ".

Isto é semelhante a perguntar "é um poder perfurar um anti-padrão?". ORMs ganhou um bom lugar na minha caixa de ferramentas, reduzindo meu código clichê e ainda sou capaz de usar SQL personalizado, se necessário. Então, se é um anti-padrão, com qual padrão ele vai contra?

Minha resposta é não, há muitos ORMs maduros por aí que tornam sua vida muito mais fácil e tornam seu código mais compreensível. Isso significa que você não precisa entender SQL, pelo contrário.

Um bom ORM pode levar a muito menos código (e muito menos repetição) em um projeto, e nada é tão strongmente correlacionado com bugs quanto a quantidade de código original.

ORMs são geralmente projetados para lidar com os casos de uso mais comuns para trabalhar com bancos de dados. Consultas complexas ainda precisam ser escritas explicitamente. Mas eu seria strongmente desconfortável escrever consultas explícitas para cada interação do banco de dados. Na maioria dos casos, isso é uma perda de tempo.

Usar um ORM em vez de aprender SQL é uma péssima ideia. Se você não sabe exatamente o tipo de SQL sendo gerado, se você não entende os problemas N + 1 e como otimizar, isso definitivamente causará mais danos do que benefícios. Eu sinto, porém, que sou muito mais produtivo usando um ORM. Eu prefiro o Rails ActiveRecord, que não tenta fingir que não há banco de dados e não fica no seu caminho se você só precisa escrever SQL. Eu me preocupo, porém, com o fato de algumas pessoas confiarem nos idiomas que vêem profundamente, sem um profundo entendimento do que estão fazendo.

Minha experiência: estou usando o NHibernate com o Linq2NHibernate.

Prós:

• Ele se livra de "Magic Strings", ou pelo menos oferece um lugar único para colocá-los
• Isso me permite trabalhar em um paradigma OO o tempo todo
• O código é mais fácil ler
• O código criado no topo é mais fácil de alterar
• Ele permite que você troque seu banco de dados relacional real sem manter dois repositórios separados (raramente feito, mas isso é um grande benefício se você precisar dele).

Contras:

• O código é mais difícil de escrever , porque
• Não é uma abstração suficiente - você ainda precisa estar intimamente familiarizado com o que está fazendo em segundo plano

Eu vou dizer que isso não corresponde à promessa que a maioria das pessoas inicialmente espera. Eu não culparia alguém por dizer que é um anti-padrão. Eu acho, no meu caso, que ainda preciso fazer testes de integração em um banco de dados SQLite para ter certeza de que minhas consultas Linq2NHibernate realmente funcionam. Então, realmente, se você está fazendo testes de integração contra um banco de dados relacional real de qualquer maneira, então isso elimina o problema com "seqüências mágicas".

Se eu fosse iniciar um novo projeto, não tenho certeza se usaria um ORM ou não. Eu provavelmente faria, mas não posso dizer com certeza que você deveria. Eu diria que é como a diferença entre escolher C ++ ou Java / .NET para o seu projeto: você vai precisar da flexibilidade com que trabalha em um nível mais baixo, ou prefere trabalhar em um nível mais alto e (supostamente) ser mais produtivo? A resposta normal é trabalhar em um nível tão alto quanto você pode se safar com . Isso geralmente significa usar um ORM.

A força de um ORM é que ele permite modelar o comportamento do aplicativo usando técnicas orientadas a objetos. Em um mundo cuidadosamente projetado, você tem uma camada do aplicativo em que a linguagem da empresa atende perfeitamente à linguagem da equipe de desenvolvimento. O ORM é um facilitador disso, se o ORM for usado de maneira sensata.

A fraqueza é que o número de pessoas que realmente realmente obtêm programação orientada a objetos é bem pequeno. Muitas pessoas escrevem espaguete e almôndegas, com objetos altamente acoplados que têm pouco comportamento próprio e o comportamento real acaba em hediondas classes "Service" e "Manager" de 8000 linhas, e esse código é muitas vezes tão intrincado que todos ficam com medo. de mudá-lo porque eles não podem descobrir quais serão os efeitos colaterais.

Além disso, muitas pessoas realmente não entendem o modelo relacional. Um ORM não os ajudará a obtê-lo e não os ajudará abstraindo o modelo relacional. Ele apenas permite que você se concentre em sua camada de domínio logo no início e acerte isso antes de começar a ficar muito preocupado com o design do banco de dados. Se for bem aplicado, com a ajuda de ferramentas de migração de esquemas sensatas, o ORM poderá ajudá-lo a evitar a acumulação de dívida de código.

Criei aplicativos nos quais um ORM mantinha o código do aplicativo simples, legível e testável e tinha um desempenho razoável. Eu também mantive aplicações onde o padrão foi mal utilizado e o código foi complicado, não testável, lento e frágil; Acontece que o ORM em si tinha pouco a ver com isso, exceto que em vez de escrever um código ruim que modelava mal o domínio do aplicativo, a equipe de engenharia legada escreveu um código ruim que modelou mal o domínio do aplicativo E código de camada de serviço ruim que negligenciou todos o valor que seu ORM poderia fornecer a eles.

Os ORMs não farão com que você seja mais inteligente, mas nas mãos do desenvolvedor certo, pode levar a um código mais sustentável e de melhor qualidade.

Talvez a resposta esteja no inverso da sua pergunta: Armazenar os dados do seu aplicativo em algo outro é melhor do que um banco de dados relacional? Que problemas você está eliminando e que outros problemas você vai resolver? Você pode viver sem a capacidade de cruzar facilmente seus dados (junções) ou filtrar rapidamente os registros desejados com base em vários critérios? Você não precisa de suporte sólido a transações (supondo que sua alternativa não tenha)? Nem todos os aplicativos precisam de um armazenamento de dados sempre consistente e completo.

Eu acho que o verdadeiro anti-padrão aqui pode estar usando um banco de dados relacional quando você não precisa de um. Se você precisa de um, então você precisa de ORM, e definitivamente não é um anti-padrão.

ORM é uma ferramenta. Como todas as ferramentas, quando usadas adequadamente, elas funcionam muito bem. Quando usado de forma inadequada, precisa de um martelo maior e de uma fita adesiva.

No caso do projeto atual em que estou trabalhando, ele será mantido por não desenvolvedores (engenheiros mecânicos, para ser preciso) e por isso precisa ser simples e fácil de descobrir. Levará vários anos até que esse grupo tenha um orçamento para contratar desenvolvedores (presumindo que o próximo presidente não abole a agência envolvida), de modo que as futuras capacidades de manutenção sejam um fator importante em nossas considerações.