Houve um tempo em que simplesmente não haviam opções quanto a manipulação do banco de dados, tinhamos necessariamente que incluir código SQL manualmente dentro do código das aplicações. Mas, felizmente, com o passar do tempo, surgiram soluções alternativas, incluindo os famosos frameworks ORM(Object-Relational Mapping), e graças a eles passamos a ter uma excelente opção para esta questão. No entanto, conforme adianta o título deste post, essa é a melhor solução possível?
Eu sempre acreditei que sim, e em parte ainda acredito. Inserir instruções SQL dentro de uma aplicação torna, ao meu ver, o código pouco elegante como um todo, uma vez que o SQL por si só não é exatamente uma linguagem bonita. Sendo assim, acabamos tendo parte do código com um nível de abstração satisfatório e a outra parte… bem, a outra parte é SQL. E mesmo se isolarmos o código SQL apropriadamente, o que, convenhamos, é o mínimo que temos a fazer, ainda assim fica feio.
Além do fato do SQL não ser mesmo uma linguagem bonita, a raiz deste problema repousa na mistura do modelo relacional com o paradigma orientado a objetos, supondo que está sendo utilizado estes dois modelos, que são, respectivamente, os mais populares para SGBDs e para linguagens de programação.
A propósito, ao contrário do que muitos pensam, o maior benefício dos frameworks ORM é justamente abstrair o modelo relacional, permitindo assim que nós trabalhemos unicamente com objetos. É um erro comum pensar que eles foram criados primariamente para possibilitar trocas de SGBDs, já que esse tipo de coisa está longe de ser comum.
Mas, apesar do SQL inegavelmente piorar estaticamente o código de um sistema, temos que considerar que estamos falando do melhor dos cenários. Há casos em que simplesmente não é possível usar um framework como Hibernate ou ActiveRecord ou qualquer outra solução que abstraia o modelo relacional, seja por problemas relacionados a performance ou por limitações da estrutura organizacional, dentre outros fatores limitantes.
Um exemplo de um cenário com tal limitação foi apresentado no Rio on Rails. Lá, o Eduardo Rocha, criador do site O Curioso, revelou que devido a problemas que afetavam consideravelmente a performance do site, teve que incluir algumas instruções SQL diretamente, ao invés de usar o excelente suporte oferecido pelo ActiveRecord. Portanto, neste caso, foi preciso abdicar da conveniente e amigável interface oferecida pelo framework ORM, no caso o ActiveRecord, em prol de uma melhor performance no site, uma vez que isso sim afeta diretamente os usuários.
Sendo assim, respondendo a minha própria pergunta, eu acredito sim que quanto menos código SQL uma aplicação tiver, melhor. Melhor para ela e para os desenvolvedores que a manterão. E se essa quantidade signigicar nenhum código SQL, melhor ainda.
Entretanto, no mundo real, como vimos acima, nem sempre isso é possível, e como desenvolvedores de software nós temos que identificar estes cenários que constituem uma exceções. Até porque, no fim das contas, o nosso foco é criar software que resolva problemas, e para isso as vezes temos que criar software feio do ponto de vista do código fonte. Até porque, o problema mais importante a ser resolvido não é o nosso, e sim aquele que originou o desenvolvimento do software em questão.
Hoje chegou a minha cópia do Repensando a web com Rails, que é o primeiro e ainda único livro com conteúdo original sobre Rails publicado no Brasil, sendo o Fabio Akita o autor do livro.
Eu sei que ultimamente não tenho postado com muita frequência, e, pra ser sincero, isso não vai mudar, pelo menos não nos próximos dias. Esse post é mais pra avisar que eu irei viajar daqui a algumas horas, e, como sou um blogueiro muito responsável, não deixei nada pronto para ser postado enquanto estiver fora, portanto o marasmo vai continuar batendo ponto neste blog por mais um tempinho.
Comentários Recentes