Modelo relacional prejudica a asbtração

Modelo relacional prejudica a asbtração

Nos últimos tempos venho intrigado pensando porque a cultura Java se volta tanto ao modelo VO-DTO-BO que se popularizou, nas minhas investigações empíricas descobri um dos causadores e portanto levanto a hipótese que o modelo relacional pode provocar uma naturalidade na abordagem desse modelo.

Lembro que fiz um curso ano passado pago por voces (o governo pagou) de análise de sistemas orientado a objetos e aprendi segundo o professor, que um modelo eficiente em java é construir uma classe para cada tabela, uma action, um value object e um Business Delegate sempre. Assim como receita de bolo, e se dependendo da tela eu deveria criar um DTO para trabalhar em cima dos dados especificos da tela em questão.
Detalhe importante, isso para qualquer sistema, desde aquele cadastro de locadora (Hello World de faculdade) à mega-hiper-supergerenciador financeiro. Vale dizer que o curso não me trouxe nada significativo, seu dinheiro foi totalmente disperdiçado, mas pior, deve ter confundido umas duas dúzias de programdores não-java (eu era o único que trabalha com java).

Bancos relacionais são os vilões

Desde que os Bancos de dados relacionais se firmaram no mercado que todo desenvolvimento é orientado a relacional. Observe que o desenvolvimento orientado a eventos que fez tanto sucesso com Visual Basic e Delphi é basicamente uma camada de manipulação das tabelas de um banco relacional. A orientação a objetos também sofre com isso. Não a orientação em si, mas a maioria dos desenvolvedores.

É evidente que o modelo relacional é eficientíssimo e trouxe uma evolução em todos os aspectos na manipulação dos dados, quem se lembra quando programava sem banco sabe muito bem disso. Cada projeto basicamente voce tinha que construir seu próprio banco de dados, garantir na aplicação concorrência e a segurança, entre outras coisas. Não sou tão velho, mas lembro que bancos de dados no Brasil eram luxo na década de 80 e ainda na primeira metade da década de 90, voce não tinha opções como existem hoje, muito menos cultura.

Com a popularidade dos bancos de dados, todo o trabalho de manipulação ficou resumido ao SQL. Isso evidentemente causou um consenso imediato no mercado, dificilmente um projeto que precise manipular dados e persistí-lo (quase todos) se dá ao luxo de não usar um SGBD. Toda a orientação a eventos foi por anos beneficiada pelo uso do SGBD.

A orientação a objetos se firmou como um conceito padrão de mercado pelo sucesso de linguagens como Java (que pela primeira ves na história uniu o mercado ao ambiente acadêmico, antes o que era sucesso em um como Delphi ou VB, não era usado em outro como C) que inspiraram outras como C# e que essa OO é a base de toda linguagem moderna como Ruby. Mas todo projeto usa os SGBDs que está baseado no modelo relacional e se choca com o desenvolvimento orientado a objetos.

A cultura relacional é ainda dominante e será em muito tempo, inclusive que a grande maioria dos desenvolvedores inciam em conceitos que não o orientado a objetos e difcilmente aprendem de forma correta, se limitando a imitarem o modelo relacional com uma linguagem OO.

Mapeamento Objeto Relacional

O mais comum que já presenciei é iniciarem um projeto pelo modelo relacional do banco ou influenciados por ele, mesmo quando se inicia modelando as classes, todos os diagramas já são pensados em como vão ficar como Entidades.

Isso é muito comum, primeiro inicia o modelo E/R, depois vai fazendo as classes e se aplica toda a OO do projeto, por isso fica quase impossível uma cultura que não caia na tentação de simular as tabelas como classes, daí surgirem os famigerados VOs diferentes do que determina o Pattern.

No mundo Java, a arquitetura Entidade-Classe, onde cada entidade do modelo relacional possui uma classe correspondente não é o melhor mapeamento, quando não o pior. Mas essa cultura de se pensar no modelo relacional provoca essa associação

Hoje com ferramenta como Hibernate, o custo de desenvolvimento do mapeamento cai drasticamente, mas mesmo assim não faz milagres, ainda moldamos certos relacionamentos pela característica relacional da coisa.

Os testes unitários tambem ajudam a isolar o aspecto de tratamento de dados da aplicação, mas se você trabalha sem um ambiente ágil que siga rigorosamente uma metodologia que prioriza os testes unitários, fica quase impossível não cair na tentação de implementar diretamente. Precisa muito autocontrole para não burlar a ordem do desenvolvimento.

Recentemente iniciei em um projeto novo de desenvolvimento e caímos na modelagem do banco, foi muito trabalhoso tentar incutir nas pessoas que a modelagem OO nada tem a ver com o modelo E/R e que esse poderia ficar para uma etapa posterior ao desenvolvimento do domínio da aplicação, pelo menos dos casos trabalhados, mas a resistência é enorme a uma abordagem que não possuam um banco diretamente.

Aplicar um desenvolvimento OO puro no domínio da aplicação hoje é dificil pela cultura dos bancos relacionais mas não impossível, não temos cultura suficiente para isso, basta dizer que no Brasil OO ainda é novidade comparado com toda a literatura e situação na civilização mas chegamos lá.

Minha fé se concentra nas ferramentas de mapeamento como Hibernate que influenciaram especificações como a JPA.

Veremos.

1 thought on “Modelo relacional prejudica a asbtração”

Comments are closed.