Conforme o .NET Core avança para acomodar funcionalidades básicas de bancos de dados como views e stored procedures, desenvolvedores procuram em outros lugares para suas necessidades de acesso a dados. Aqui estão algumas das opções mais populares.
LLBLGen Pro Runtime Framework
O LLBLGen Pro Runtime Framework é um ORM opcional que trabalha em conjunto com o modelador de entidades LLBLGen. Dizemos que é opcional porque o LLBLGen também pode trabalhar com outros ORMs como o Entity Framework.
Assim como o Entity Framework, o LLBLGen Pro Runtime Framework é um ORM totalmente no estilo de orientação a objetos. Mas ele se diferencia de muitas maneiras, a primeira é a ênfase em performance. Apesar do EF Core ser significantemente mais rápido que o clássico Entity Framework, ambos ainda são consideravelmente mais lentos que outros ORMs. Frans Bouma, autor do LLBLGen Pro, mantém uma incrível comparação de performance materializando a velocidade de diversos acessos a dados .NET / Implementações de ORM.
O LLBLGen Pro Runtime Framework também difere do EF/EF Core por não se limitar ao contexto. Cada entidade rastreia suas próprias mudanças, possibilitando a manipulação de um objeto grafo em memória sem manter um contexto aberto. (O qual fará o DBA feliz porque não manter um contexto aberto também significa não manter uma conexão aberta, a qual poderia interferir no pool de conexões da base de dados.)
Assim como a maioria dos ORMs para .NET Core, há algumas limitações com a versão do Core do LLBLGen Pro Runtime Framework. No entanto, isso é geralmente limitado pelas funcionalidades não existentes no próprio .NET Core, como o TransactionScope não ser suportado pelo SqlClient ou poucos objetos serem binariamente serializáveis.
Dapper
Na outra ponta da escala está o micro-ORM já conhecido, Dapper. Geralmente mencionado como o ORM mais rápido, o Dapper está consistentemente no, ou próximo do, topo dos benchmarks de ORM .NET.
Como o Dapper é praticamente limitado a chamar SQL cru e extrair resultados, funciona essencialmente da mesma forma no .NET e no .NET Core. Diferente dos ORMs completos, o Dapper não provê nenhuma capacidade de geração de SQL. Isso tende a torná-lo mais verboso que outros ORMs, apesar de muitos desenvolvedores não confiarem no SQL gerado por ORMs.
LINQ to DB
O LINQ to DB se auto descreve como "um passo além dos micro-ORMs como Dapper, Massive, ou PetaPoco". Ele não possui diversos recursos que causam problemas de performance ao Entity Framework, como o rastreamento de mudanças.
Os Joins no LINQ to DB não são muito úteis. No EF, qualquer coisa que consideremos como "join" é, na verdade, tratado como um objeto ou coleção filho. O SQL gerado com certeza irá utilizar joins, mas serão desfeitos quando o grupo de resultados é devolvido como objetos.
No LINQ to DB você realmente tem joins. Mais especificamente, "left joins" e "inner joins". A sintaxe é um pouco estranha se estivermos acostumados com as interpretações de LINQ do EF, mas isso combina melhor em como a base de dados funciona atualmente.
DevExpress XPO
O eXpressPersistent Objects (XPO) é uma outra oferta comercial. O usuário -GrapH- do Reddit disse isso sobre ele:
Venho utilizando o DevExpress XPO por 11 anos até agora, e nesse último outubro ele suportava o .NET Standard 2.0. Apesar de ser um produto comercial, seu primeiro .NET beta com suporte .NET Core (v17.2.2) será de graça para todos. Atualizações futuras serão pagas, mas elas incluem o visual designer e suporte técnico. Enquanto este ORM é diferente do EF e é mais velho (a não ser que eu esteja enganado, sua primeira versão foi lançada para .NET 1.1), ele basicamente tem tudo que precisamos para aplicações de escalas muito diferentes. Confiram https://github.com/DevExpress/XpoNetCoreDemos para demos e tutoriais.
Qual é o seu favorito?
Existem muitos outros ORMs disponíveis para .NET Core. Se há algum que você esteja usando por alguns meses, compartilhe o que pensa sobre ele.