Não se esqueça que pode contar com Stored Procedures


Um caso real: em 98 estava numa sessão de JAD (Joint Application Development) ajudando a definir a tecnologia de um projeto que seria orientado a objetos quando chegamos à questão relatórios. Perguntei ao grupo se iriam usar um gerador de relatórios e ... silêncio. Todos olharam para mim e para o consultor que seguiria com eles na modelagem e construção do sistema. Num salto, o consultor afirmou: "faremos nossos relatórios usando OO".


Perguntei ao grupo se conheciam o impacto desta decisão... silêncio.


Eu tinha duas preocupações: produtividade e desempenho.


Comecei então com meu exemplo costumeiro. Um relatório para listar Bancos, Agências e Contas.


No modelo OO, construímos um loop sobre a lista de bancos, dentro dela outro loop sobre as agências para, num loop final, alcançar as contas. Se não houver um bom mapeamento entre o relacional e objetos, isto costuma provocar um número enorme de selects (1 para os n bancos, n para as m agências e m para as contas = 1*n*m).


Em contraste, usando o poder do join, no relacional, seria possível trazer os dados e uma única querie.


Depois das explicações, voltei ao grupo. Vocês não preferem um gerador de relatórios?


Olhos no consultor. Logo ele nos dá seu ponto de vista: “sou matemático e entendo que temos que uniformizar o modelo de programação para um único modelo: o OO”.


Brincando, respondi: “além de engenheiro sou carioca” (risos – eu estava em São Paulo. Somos famosos aqui pelo jeitinho ou, pior, a malandragem). “Se tiver que misturar meu paradigma para tornar a engenharia e o custo viáveis, não duvido muito.”


Fomos à votação e o modelo OO ganhou. Não usaram um gerador de relatórios.


Ouvi anos depois que o projeto não foi bem. Não sei se por causa dos relatórios, mas desconfio que pela mudança cultural e excesso de idealismo.


Conto isto tudo para poder dar um conselho: é muito bom poder contar com queries Linq que trazem em um único select Banco, Agência e Conta. Mas não se esqueçam que, quando estiverem usando um ORM, o algoritmo tenderá a um ninho de loops sobre a coleção de objetos em memória – o que também é ruim. Neste caso, operações relacionais mais complexas podem ser necessárias. Lembre-se: não tenha medo de usar stored procedures, se necessário.


Comments (2)
  1. werhmuller says:

    concordo com você Otavio. Tenho “caído” em alguns dilemas sobre quando usar SP´s ou não mas geralmente tenho usando em casos semelhantes à este. Penso que para algumas tarefas, o Banco de Dados resolve bem melhor que a própria OO.

  2. Olá Otávio,

    Acho que a questão nem são as SPs, mas o paradigma, mesmo. E a prisão que algumas pessoas se colocam com eles.

    Os bons arquitetos sabem que devemos aplicar as melhores práticas em cada pedaço da aplicação, e sabem quando aplicar boas práticas e quando não aplicar.

    No caso que você relatou, um modelo de única query, bem relatório mesmo, onde eu passo o modelo do banco à frente, é a melhor escolha. O problema é colocar isso junto com o mundo OO. Aí que entra, por exemplo, as Anti-corruption layers, proposta do Evans no DDD. Funcionam perfeitamente. E esta é só uma das opções.

    Quem sabe se o consultor em questão lesse mais, não seria tão… “matemático”.

    Porque o mundo de tecnologia quer ser binário como as máquinas? Somos engenheiros, arquitetos, codificadores, e somos, acima de tudo, pessoas, com criatividade e flexibilidade. E são justamente estas últimas qualidades que nos dão o poder para utilizar OO e um “Table Module” em uma mesma solução, e com sucesso, por exemplo.

    Um abraço!

    Giovanni Bassi

Comments are closed.

Skip to main content