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

21

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).

.net orm Wayne Molina
fonte
+1: você ainda precisará de uma linguagem de consulta, não importa o que seja, portanto, você também pode usar algo familiar como linq ou sql, mas retornar tipos anônimos como no seu exemplo não parece mapear um modelo relacional para um domínio concretizado modelo. Isso é tão estranho para mim.
Steven Evers
Sim, eu não consegui encontrar um exemplo concreto de Dapper, no site, literalmente, var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });e depois dog.First().Ageacessar as propriedades.
Wayne Molina
5
O exemplo não retorna um tipo anônimo, a palavra-chave "var" pode ser usada no lugar de um tipo concreto em C # para salvar a digitação extra; essa consulta retornaria IEnumerable <Person>.
Ed James
1
O principal motivo é menos sobrecarga, pois é necessário fazer o check-in constantemente dos sprocs e lembre-se de atualizar duas dúzias de arquivos SQL, sem mencionar a necessidade de ter procs armazenados para o código CRUD trivial.
Wayne Molina
2
O principal benefício de não usar sprocs para manter todo o código (e eu uso o código de propósito aqui, incluindo SQL e seus outros idiomas de escolha) no mesmo sistema de controle de versão. Eu ainda não encontrei um bom banco de dados entre bancos de dados VCS.
Ed James

Respostas:

12

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) .

Ed James
fonte
Existem bibliotecas que podem ser usadas como invólucro para esses micro orms, o que pode reduzir o problema que você está mencionando nos erros de digitação. Por exemplo: Simple Crud add-on para Dapper
Srivathsa Harish Venkataramana
3

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
Christophe Debove
fonte
1

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.

Gelo preto
fonte