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

• Anonymous
  August 11, 2008
  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.

• Anonymous
  August 17, 2008
  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