Que tipo de projetos de desenvolvimento da Web se beneficiam do uso do ORM?

Começarei dizendo que fiz 95% do meu trabalho de banco de dados usando SQL. Recentemente, fiz uma investigação de várias ORMs, como NHibernate e Doctrine.

Eu posso ver as vantagens de não precisar conhecer muito SQL e a portabilidade do banco de dados que um ORM fornece. Mas também vejo que o conhecimento do SQL tornará o trabalho com um ORM mais eficaz e só posso pensar em uma vez na minha carreira que a maior mudança de um aplicativo seria o fornecedor do banco de dados.

Como estou muito confortável escrevendo SQL e aparentemente não estou percebendo os benefícios frequentemente ensinados do uso de um ORM, minha pergunta aos usuários pesados ​​do ORM é esta:

Que tipo de projetos de desenvolvimento da Web se beneficiam mais com o uso do ORM?

(Quase) todos os aplicativos se beneficiam do ORM.

Primeiro, não concordo com as vantagens que você lista para o ORM .

• Usar ORM não significa necessariamente que você não precisa conhecer SQL. Um conhecimento de SQL ajudará a entender o que a ferramenta ORM está realmente fazendo, o que é especialmente útil durante a depuração. Além disso, o SQL pode realmente ser necessário para desenvolver consultas complexas que estão além da capacidade do ORM escolhido.
• E, como você diz, a portabilidade raramente é uma preocupação na vida real.

Em vez disso, os benefícios reais do ORM são:

• O ORM economiza tempo do programador porque economiza toneladas de lógica CRUD no SQL
• muitos ORMs incluem lógica de cache complexa etc., difícil de gravar e depurar. Além de economizar tempo, isso pode melhorar a confiabilidade e a capacidade de manutenção do seu aplicativo (ou pelo menos economizar o tempo necessário para obter os mesmos resultados)
• os melhores ORMs têm uma comunidade de usuários que ativamente desenvolvem, mantêm e dão suporte ao produto. A comunidade em torno do SQL personalizado é, na melhor das hipóteses, um pouco menos focada nos problemas que precisamos resolver.

Como você comenta, um lado negativo do ORM é a perda de desempenho. No entanto, isso geralmente pode ser compensado gastando mais hardware.

Normalmente, o tempo do programador é mais caro que o hardware; portanto, o ORM é geralmente uma boa opção, em vez de codificar manualmente o SQL.

O ORM é melhor para aplicações com muita lógica de banco de dados CRUD bastante simples. ORM é menos eficaz para :

• Aplicativos que precisam de pouco / nenhum acesso ao banco de dados.
• Aplicativos que dependem amplamente de consultas complexas e muito pouca lógica CRUD simples
• Situações em que o desempenho é crítico, mas onde não há possibilidade de implantar hardware mais rápido

Na minha experiência, essas situações são raras. Daí a minha resposta.

Também me sinto confortável escrevendo SQL. Também me sinto muito mais confortável em não precisar escrever SQL, além de não me preocupar em conectar, desconectar, agrupar etc em um banco de dados.

Então .. eu vou responder o negativo da sua pergunta. Os únicos projetos de desenvolvimento da Web que NÃO se beneficiam de um ORM são os que não estão falando com um banco de dados. Que eu acredito ser a minoria (se houver).

Com base na minha experiência com o ASP.NET WebForms, proponho que os projetos da Web que utilizam estruturas da Web com estado são os que mais se beneficiam com o uso de um ORM.

Com uma estrutura estável, a marcação é gerada automaticamente nos bastidores, com base na hierarquia dos controles ativos do servidor. É tentador fazer com que esses controles sejam carregados e persistam seu estado automaticamente no banco de dados. É aqui que o ORM ajuda.

Você meio que abstrai o final do pipeline (saída HTML) e é naturalmente convidativo lidar com o início (fonte de dados) da mesma maneira, para que você permaneça apenas dentro da lógica de negócios no código do aplicativo.

Não que eu não esteja dizendo que essa é uma boa maneira de fazer as coisas. É exatamente onde o ORM se encaixa naturalmente.

Nos aplicativos em que você possui um modelo de objeto grande e muito conectado, um ORM evita que você escreva as mesmas junções repetidas vezes.

Outro benefício é o carregamento lento, em que você deseja que uma API retorne um gráfico de objeto em que o cliente da API use apenas um subconjunto desse gráfico.

Acredito que você esteja confundindo um ORM com um DBAL .

O conceito ao qual você está se referindo é uma DBAL (Database Abstraction Layer) que permite escrever "sql" portátil que não depende do sistema de banco de dados subjacente.

Por outro lado, um ORM (que quase sempre é construído sobre um DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

Simplificando, um ORM permite converter dados de um banco de dados simples em uma representação de objeto inflada.

Projetos que não se beneficiariam com ORM seriam:

• os que não são orientados a objetos;
• os que não precisam persistir dados;
• os que usam DB orientado a objeto, portanto, não precisam de camada de mapeamento adicional;
• os que usam solução NoSQL não relacional;