Problemas entre ORM e banco de dados

A modernização de aplicações envolve conversas sobre a implementação de práticas de orientação a objetos e ORM (object relational mapping) para expandir o relacionamento com o banco de dados. Esse modelo de transição envolve a quebra de paradigmas tradicionais como ter o banco de dados como ponto central da aplicação e com frequência surge discussões.

A visão mais tradicional de banco de dados e aplicações está relacionada ao tradicional relacionamento de CRUD (Create, Read, Update e Delete) seguido por práticas de adicionar inteligência de aplicação no banco de dados sobrecarregando a dependência no banco de dados o que tem provocado dificuldade de escalabilidade, manutenção e sustentação visto que se de um lado trabalhamos totalmente orientado a objetos por que do outro deveríamos manter uma visão de dados.

Ao longo dos últimos 10 anos a evolução dos modelos de arquitetura de software, padrões de projetos, técnicas de desacoplamento e um maior uso de orientação a objetos padronizou a adoção do modelo de ORM (object relational mapping) justamente por permitir do lado da aplicação uma estratégia de orientação a objetos ao utilizar o banco de dados. Essa abstração proporciona do lado do desenvolvimento uma experiência diferenciada conduzindo o trabalho que antes era em dados para o mesmo modelo de orientação a objetos.

A evolução de qualquer estratégia gera sempre desconforto e por incrível que pareça o ORM sempre gera muita conversa. O processo de transição permite escalar mais facilmente o desenvolvimento, simplifica a operação e manutenção do software e abstrai o relacionamento com o banco de dados evitando sujar todo o código da aplicação com comandos “T-SQL…” difíceis de serem mantidos. Uma consulta tradicional é convertida em uma consulta orientada a objetos deixando toda a comunicação com o banco de dados para o ORM.

Ao longo dessa transição venho acompanhando e resolvendo os “paradigmas” e “resistências” colocadas mostrando que no modelo de serviço o banco de dados é um repositório que inclusive a depender do cenário não é um dos principais e de forma alguma tem que ser o ponto focal da aplicação.

Eu tive a oportunidade de acompanhar uma situação bem interessante onde no meio do projeto construído completamente do zero e com foco em alta performance surgiu um relato que o ORM “Entity Framework” não funcionava e que o reclamante tinha se dado ao trabalho de construir uma “Stored Procedure” muito mais eficiente para atender o cenário.

A minha primeira ação foi mover a nossa equipe de engenharia para estudar o cenário proposto. Com frequência somos “desafiados” nesse tipo de discursão e essa chegou digamos em um formato “bem diferente” tamanho o sentimento empregado pelo reclamante e energia empregada em criar esse entrave no projeto.

Ao estudar o cenário notamos rapidamente que a “Stored Procedure” por si só era completamente ineficiente visto que já no plano de execução ficou evidente a imensidão de loops e gargalos até se obter o devido dado. Não preciso nem comentar aqui o código “monstro” da procedure, tabelas temporárias envolvidas… e quantidade de sub querys.

O resumo desse cenário foi que o mindset estava orientado ao banco de dados e tinha erros graves na modelagem provocando todo esse desgaste nas consultas. No lugar de atacar a causa raiz foi lançando todas as energias contra o “Entity Framework”. O reclamante dedicou um enorme tempo criando uma “Stored Procedure” para esconder o problema de modelagem criado inclusive por ele mesmo ao invés de atuar na causa raiz.

Depois de um mergulho mais profundado foi proposto uma mudança arquitetural no projeto de dados reorganizando a modelagem para ser eficiente sem comprometer os dados. Esse ajuste permitiu ao ORM ou a “Stored Procedure” realizar a consulta com eficiência. Uma plataforma de ORM como o Entity Framework vem como padrão pronta para atender cenários dos básicos aos avançados e nesse caso o erro de projeto no banco de dados foi propagado para o ORM.

O próprio Entity Framework deve ser customizado para cenários ultra otimizados. Utilize os parâmetros disponíveis desligando funcionalidades. Dessa forma você consegue o melhor dos dois mundos. Experimente colocar água em uma Ferrari que está aguardando a gasolina. Se colocar uma gasolina ruim por melhor que seja o motor não terá todos os benefícios.

Nós cenários mais críticos de aplicação a última coisa que fazemos é ir no banco de dados. Por isso é importante desenvolver um projeto de aplicação orientado a uma estratégia e não a um ponto focal especifico. Não defendo um radicalismo em ORM, mas um conceito padrão como “ORM First” apoiado por uma estratégia de arquitetura de software, serviços distribuídos, cache que permita escalar a aplicação independente do banco de dados.

Em resumo a minha recomendação é olhar para o projeto como um todo e compreender que não é o ORM que compromete a performance e sim o contexto do projeto. Pratique o desapego e se permita experimentar novas experiências e estratégias modernas no desenvolvimento de software.

Para saber mais:
– Problemas ao usar o banco de dados para regras de negócio
– Desenvolver um SaaS não é criar um website

Até a próxima !!!

Ramon Durães

CEO, 2PC

MVP, Visual Studio

PSM, CSM, LKU

Esse artigo é um oferecimento da 2PC. Entre em contato para modernização de aplicações, Devops, Visual Studio e arquitetura de software.