Quais são alguns dos benefícios de um "Micro-ORM"?

Eu estive analisando os chamados "Micro ORMs", como o Dapper, e (em menor grau, pois depende do .NET 4.0) maciço, pois pode ser mais fácil de implementar no trabalho do que um ORM completo desde o nosso sistema atual é altamente dependente de procedimentos armazenados e exigiria refatoração significativa para funcionar com um ORM como NHibernate ou EF. Qual é o benefício de usar um desses em um ORM completo? Parece apenas uma camada fina em torno de uma conexão de banco de dados que ainda obriga a escrever SQL bruto - talvez eu esteja errado, mas sempre me disseram que o motivo dos ORMs em primeiro lugar é que você não precisava escrever SQL, pode ser gerado automaticamente; especialmente para junções de várias tabelas e relacionamentos de mapeamento entre tabelas que são difíceis de fazer em SQL puro, mas triviais com um ORM.

Por exemplo, vendo um exemplo de Dapper:

var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });

Como isso é diferente de usar uma camada de dados do ADO.NET, exceto que você não precisa escrever o comando, definir os parâmetros e suponho que mapeie a entidade de volta usando um Construtor. Parece que você pode usar uma chamada de procedimento armazenado como a string SQL.

Há outros benefícios tangíveis que estou perdendo aqui, onde um Micro ORM faz sentido usar? Eu realmente não estou vendo como isso está salvando algo da maneira "antiga" de usar o ADO.NET, exceto talvez algumas linhas de código - você ainda precisa escrever para descobrir qual SQL você precisa executar (o que pode ficar peludo) e você ainda precisa mapear os relacionamentos entre as tabelas (a parte na qual os ORMs do IMHO ajudam mais).

Benefícios:

• Desempenho semelhante a um SqlCommand bruto com DataReader e análise.
• Não é necessário rolar sua própria camada de conversão para o DataReader.

É bem isso, para ser honesto. Você tem um invólucro muito leve para suas conexões sql que fará a conversão do objeto para você. Obviamente, você pode ajustar as consultas sem precisar lidar com nenhum SQL gerado automaticamente.

Contras:

• Nem um pouco mais seguro. Se você digitar um erro de digitação no SQL, o servidor de IC não detectará, mas espere que seja detectado durante a UI automatizada ou o teste funcional.
• Uma dor para manter. Você tem várias instruções SQL embutidas que fazem várias consultas sem vínculos fortes com a arquitetura do banco de dados. Isso pode facilmente levar a consultas que são "deixadas para trás" quando a estrutura do banco de dados subjacente é alterada, o que, novamente, você não verá no momento da criação.

Eles têm o seu lugar e são uma ferramenta muito eficaz que pode tirar parte do "trabalho burro" dos desenvolvedores ao interagir com o banco de dados, mas, na realidade, eles simplesmente não podem substituir o ORM completo em nenhuma escala em larga escala. sistema para consultas que não são críticas para o desempenho, simplesmente devido ao aumento do custo de manutenção.

Se você está enfrentando problemas de desempenho em consultas ao banco de dados, sugiro que seria melhor usar essas estruturas de mapeamento apenas com procedimentos armazenados, a fim de obter uma indicação em tempo de compilação se seu SQL é válido (além dos benefícios adicionais de desempenho) .

No site do micro ORM PetaPoco, ele explica algumas vantagens com outros ORM. para explicar mais

O PetaPoco é um micro-ORM pequeno, rápido e de arquivo único para .NET e Mono.

• Como o Massive, é um único arquivo que você adiciona facilmente a qualquer projeto
• Ao contrário do Massive, ele trabalha com POCOs de tipos fortes
• Como o Massive, agora também suporta Expandos dinâmicos - leia mais
• Como o ActiveRecord, ele suporta um relacionamento próximo entre objeto e tabela de banco de dados
• Como o SubSonic, ele suporta a geração de classes poco com modelos T4
• Como o Dapper, é rápido porque usa a geração dinâmica de métodos (MSIL) para atribuir valores de coluna às propriedades

Como isso é diferente de usar uma camada de dados do ADO.NET, exceto que você não precisa escrever o comando, definir os parâmetros e suponho que mapeie a entidade de volta usando um Construtor. Parece que você pode usar uma chamada de procedimento armazenado como a string SQL.

Acredito que esse seja o principal benefício de um Micro-ORM. Para obter os outros benefícios de um ORM, você precisaria usar um completo. Isso e o código são relativamente menores; portanto, se você precisar personalizá-lo, seria mais fácil.