Seções iMasters
Banco de Dados + Desenvolvimento + Software

Eis que surge uma nova relação entre desenvolvedores e banco de dados

As tecnologias empregadas no desenvolvimento de software têm evoluido muito ao longo dos últimos 20 anos e em uma velocidade tão grande que algumas pessoas acabaram por não perceber esse ciclo de melhorias, como as das técnicas em si (como a programação orientada a objetos e as estratégias modernas de arquitetura de software e codificação), simplificando o dia a dia focando em código limpo, testável, reutilizável e integrado.

Em um passado muito distante, não tínhamos no dia a dia o conceito de orientação a objetos que temos atualmente. Estou falando de um momento do mercado onde desenvolver em camadas era entupir o banco de dados de regras de negócios baseadas em uma soma explosiva de Trigger + Stored Procedures; conceituando-se como a visão de desenvolvimento em camadas daquele momento, evoluindo a lindos modelos com procedures “maravilhosas” para todo o CRUD (Create, Read, Update, Delete) que vem contaminado projetos até hoje. Certamente você já viu essa situação em algum lugar. Agora você conhece a origem do problema e pode parar com ele.

Este é o momento de sermos muito honestos com a realidade e falar o tamanho deste problema que se iniciou no passado e ainda convive na mente de muita gente. Vamos combinar que desenvolver uma regra de negócio direto no banco de dados é um trabalho sofrível, sem depuração, sem nenhum apoio de reutilização de inteligência de software. É tipicamente um notepad com control+C / control+V; ou seja, o que foi pensando como um caminho de reutilização tornou-se um gargalo para o time de desenvolvimento e para o próprio banco de dados, que absorve funções que são do escopo do serviço de aplicações, consumindo recursos desnecessários. É fácil você comprovar e verificar que todas as empresas que fizeram isso sofrem com gargalos nas operações de banco de dados que ficam travando registros eternamente.

Quando entramos no escopo da manutenção, estamos falando de um caos generalizado que é garantir a qualidade de um código gigantesco – muitas vezes com mais de 10 mil linhas sem nenhuma infraestrutura de apoio. O fato é que ele não foi projetado para isso. Banco de dados é para atuar como banco de dados e não como servidor de aplicações. Agora imagine como vai escalar isso no ciclo do seu projeto, tendo que focar as pessoas em manter esse código ultra complicado. Muda em um ponto e estoura em dezenas de outros. Acredito que já viu essa situação em algum vizinho próximo. Está na hora de você praticar o desapego e parar de acreditar que software tem que ser desse jeito.

Ao longo dos anos, os projetos foram crescendo e os negócios foram crescendo juntamente com o número de usuários nas aplicações. Ao mesmo tempo, cada vez mais pessoas estão participando do ciclo de desenvolvimento, criando demanda por um modelo de produção de software mais organizado, utilizando práticas “reais” de orientação a objeto, padrões de projeto e codificação com regras de validação reutilizáveis e fáceis de manter disponibilizadas em um barramento de serviços (API), compartilhando e facilitando a integração entre plataformas e outros dispositivos, além de uma cobertura por testes automatizados via testes unitários, garantindo a evolução do negócio sem comprometer a qualidade do que está sendo produzido.

Enquanto estamos conversando, as plataformas de banco de dados também evoluíram muito, quebrando paradigmas do passado – que código roda mais rápido se estiver dentro do banco de dados, por exemplo. Os principais bancos de dados criam plano de execução dinamicamente, além de uma série de funcionalidades e estratégias para fazer o objetivo deles: que é oferecer a informação solicitada. Essa historinha ultrapassada ainda toca na vitrola de muita gente e parece aquela do “CD gravado em computador vai estragar o seu leitor”. Está na hora de sair do tempo do vinil e entrar no developer 4D.

Em paralelo está o DBA (Database administrator), cujo nome já deixa claro suas atribuições administrativas que foram também desfocadas ao longo dos anos, não observando que a sua importância não é criar procs e sim otimizar processos do banco de dados, manter estratégias administrativas e operações relacionadas permitindo escala. De uma vez por todas, vamos deixar claro que quem entende de negócio é o cliente solicitante e o desenvolvedor que está construindo a aplicação. O momento da revolução industrial e produção com batedor de martelo não existe mais.

Para entender melhor, imagine você trabalhando em um time de vinte desenvolvedores parados, esperando o DBA construir uma Stored Procedure e determinar a criação de um campo no banco de dados. Ainda me espanto quando vejo isso. É quase o mesmo que assistir uma tv de válvula nos tempos de hoje. Tudo bem, eu sei que você provavelmente desconhece esse tipo de tv, mas só para comparar a distância entre ela e a era SmartTV. Está na hora de acabarmos com essas lendas urbanas e assumirmos a área de desenvolvimento como tem que ser. O trabalho do DBA continua como foi pensado: “Database administrator”; e é parte importante do centro de operações, mas desculpe, não faz parte do desenvolvimento de software e sim operações.

Agora que você está ambientado, provavelmente já participou de algum tipo de conversa sobre essa questão que emerge com frequência na maioria das empresas com mais de quinze anos de mercado. O grande passo para praticar o desapego é entender que temos orientação a objetos há mais de 20 anos e até hoje convivemos com esse conflito entre código e dados, uma relação de amor e ódio que precisa ser resolvida. Chame todo o seu time e faça um DRP (discussão de relacionamento no projeto). Vamos acabar com as disputas de poder e construir um trabalho positivo para todos.

O ORM (object-relational mapping) foi criado justamente para unificar essa relação entre código e dados, padronizando o código fonte, dispensando a necessidade de escrever códigos T-SQL e, principalmente, de ser uma preocupação extra para desenvolvedores e relacionados. Ficando, então, a cargo da infraestrutura de ORM fazer essa relação e trazer uma visão do banco de dados em um formato integrado ao mundo de desenvolvimento de software com os dados tipados e orientado a objetos, simplificando a manutenção e permitindo o compartilhamento do conhecimento – isso sem falar no aumento de produtividade, pois o desenvolvedor passa a lidar com dados da mesma forma que lida com qualquer outra classe. É nesse momento que você, desenvolvedor, percebe o quanto estava gastando de dinheiro produzindo código macarrônico desnecessário. Quem curte comida italiana, como eu, deixa para consumir em casa ou no restaurante, mas não no projeto.

Agora que já estamos falando em não mais escrever regras de negócio no banco de dados e nem Stored Procedures e afins, precisamos mudar a nossa forma de pensar como um todo e entender que quanto mais simples for o código, mais escalável ele será. Ferramentas de ORM, como Entity Framework e similares, têm justamente esse papel de mapear uma tabela de banco de dados como uma classe criando um elo de integração, tornando a sua aplicação por padrão independente do banco de dados. Para o desenvolvedor, a visão de trabalho será fazer o que ele já sabe: explorar todo o potencial da linguagem de desenvolvimento e produtividade da ferramenta de trabalho integrada, como Visual Studio (Integrated development environment/Rapid Application Development).

O próximo passo é romper discursões inúteis dos resistentes na área de desenvolvimento que, sem conhecer ou testar, já gritam de imediato “Não é rápido, não confio, gosto de fazer tudo a mão, não tenho o controle”. Se você analisar o código fonte de uma aplicação em um cenário padrão de desenvolvimento de software, na maioria dos projetos o que encontramos é uma consulta ao banco de dados trazendo um volume grande de dados para que seja filtrado na camada da aplicação.

Esse é o momento de analisarmos como as consultas estão sendo implementadas hoje. No Oracle e SQLServer temos recursos como RowNumber para paginação de registros. Pergunte quem usa? Usando ORM basta pedirmos a quantidade de linhas e a página desejada que trazemos o bloco específico de registros para mostrar na tela ao usuário. Avaliando, o esforço na implementação será mínimo com uso de um simples parâmetro. É importante você ter em mente que a plataforma de ORM é otimizada para gerar a melhor consulta no banco de dados.

Trazendo a visão para um pensamento em C#, o processo é muito simples e já faz parte do seu dia a dia. Ou seja, por padrão você já é obrigado a saber e implementar orientação a objetos, então, basta instanciar a classe mapeada, efetuar as consultas e deixar o ORM gerar internamente o T-SQL para falar com o banco de dados e retornar os dados para a sua aplicação no formato de objetos. Se você está curioso para saber como ele está trabalhando, basta ligar o profile e verá a query gerada. Com o tempo nem lembrará mais o quanto você sofria e vai perceber apenas o peso do qual se livrou.

Conforme citei no inicio, a partir do momento em que você tira a inteligência do banco de dados e traz de volta para a aplicação, você terá um único local padronizado para manter o seu código fonte, que associado a testes unitários e integração contínua elevará o desenvolvimento do seu projeto para um novo patamar em produtividade e, principalmente, qualidade de software. E isso resulta em uma importante economia no ciclo de desenvolvimento, acelerando e removendo muitas dificuldades encontradas.

Considere esse tipo de resistência como fato natural do ser humano com relação a mudanças. Para se ter ideia, em 1904 passamos por um fato histórico interessante conhecido como Revolta da Vacina, no Rio de Janeiro, onde pessoas extremamente revoltadas não aceitavam a vacinação obrigatória contra a varíola com medo do vírus e hoje brigamos para ser vacinados – também por medo do vírus. Esteja atento, pois a nova geração de profissionais já não convive mais com esse fantasma. Então aproveite a oportunidade e livre-se também.

O tempo do software em caixinha já se foi! Hoje não dá para pensar em mais nada que não seja focado em serviço e para distribuição em larga escala. O seu conceito vai começar a mudar quando passar a entender que aplicações de alta performance dependem minimamente do banco de dados. No mundo do software como serviço (SaaS) não tem espaço para gargalos. Temos infraestrutura de aplicação para High Performance Web Sites como um serviço padrão de cache e Message Queue, organizando processos e filas sempre pensando em não criar gargalos na aplicação em função de outros recursos agregados.

Com a velocidade que os negócios estão mudando, não podemos mais nos dar ao luxo de fechar os olhos e continuar colhendo milho da mesma maneira, achando que essa é a melhor forma porque foi a forma que você aprendeu. Desenvolver software é um desafio diário e compete a todos nós estarmos prontos para entender as mudanças e nos adaptar para que possamos responder as demandas de negócios no tempo certo e com qualidade.

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

29 Comentários

Rafael

Ótimo texto.

Matheus

Excelente artigo! Sempre lutei contra essa história de regras de negócio no banco de dados. Uma simples migração de versão ou tipo de banco é uma dor de cabeça gigantesca.

William

Muito bom !

Vinícius

Excelente artigo!

Ronaldo

Muito bom, artigo com profundidade no assunto, escrito por quem conhece do assunto.

#ForaArtigosDe2paragrafos!

Ronaldo de Alcântara

Nossa! Excelente artigo! Parabéns!

Felipe Martins

Excelente texto. Deixou claro que desenvolver é uma ciência, que exige planejamento, que também evolui e são esperados métodos novos para buscarmos sempre os melhores resultados. O combustível evoluiu, a panela evoluiu, o uso dos recursos naturais evoluiu. O jeito de pensar também. PAREBÉNS!!!

Luiz Corumba

Sinceramente acho que SP Triggers etc etc no banco de dados com regras de negócios bem definidas é uma excelente forma de produtividade e agilidade não só para o desenvolvedor mas também para a aplicação.
Existem desvantagens (ficar preso a um SGBD) mas as vantagens (otimização, integridade dos dados, alta performance, etc) são bem maiores.
Muitos desenvolvedores não gostam de usar SP, seria por falta de conhecimento? Preguiça? ou “Assim entrego mais rápido” o produto?

    Ramon Durães

    Olá Luiz,
    Tudo bem
    Eu diria que programar código focando em reutilização exige muito planejamento e disciplina. É mais fácil chutar tudo para o banco de dados.

cleiton

Ótimo artigo, muito esclarecedor.

Freitas

Amigo, suas informações só podem está baseadas no banco de dados Access ou armazenamento em arquivo texto, tempo do Vinil. Citar exemplo de paginação como um problema para não programar dentro do banco de dados é totalmente sem rumo. Está na cara que você já tem sua opinião formada, o que é ruim para o leitor, pois o correto seria você mostrar os dois lados da moeda e deixar a cargo do leitor escolher. Programar a nível de banco de dados é muito melhor para integração, pois é só chamar a StoredProcedure a partir de QUALQUER LINGUAGEM e qualquer S.O., ou seja, é muito mais flexível, sem contar que você evita bloqueio de registros e permite que o banco de dados gerencie de forma otimizada a recuperação dos dados. O comentário do Luiz Corumbra diz tudo. Hoje os bancos de dados possuem recursos para desenvolver qualquer tipo de lógica e até mesmo programação com O.O., como no Oracle, e é uma tendência dos bancos de dados nesse sentido, como por exemplo o Mysql, Postegres e Oracle.

    Ademilton

    O artigo foi sim bem escrito, mas concordo com Freitas e Luiz Corumba quanto a argumentar que os SGBDs não ficaram parados no tempo. Evoluíram o suficiente para suportar orientação a objetos e muito bem. Pena que estes recursos são desconhecidos da grande maioria. Temos que considerar também a evolução do hardware, o que faz com que processamento no banco de dados já não seja tão assim o gargalo da aplicação. E o que dizer de um sistema que leia dados de uma tabela, levando para fora do banco (gerando tráfego), processe-os numa camada externa e depois apenas insira em outra tabela… no mesmo banco ?? Aliás, acompanho aqui um sistema de porte grande, onde o banco de dados foi relegado à função de simples repositório (nem triggers há nele) e a aplicação rodando fora trava constantemente.

      Ramon Durães

      Olá Ademilton,
      Tudo bem!!!!!
      Problema de travamento é implementação. Vamos com muita calma nessa hora. Pior ainda se codificar no banco de dados. Tenho clientes que sofrem muito ainda hoje por implementações gigantescas de Triggers onde tudo trava no banco de dados. Estamos falando de servidores de muitos reais e uso indevido provoca enormes locks congelando todo mundo que está usando. Até 1999 falávamos muito ainda em Client/Server. De 1999 iniciamos o desapego com entrada mais firme da internet e aplicações de negócios online. Estamos em 2012 e não podemos continuar trazendo pensamentos cliente/server para os dias atuais uma vez que teremos dificuldades em dar os próximos passos criando códigos escaláveis e serviços de alta disponibilidade.

    Ramon Durães

    Olá Felipe,
    Tudo bem
    Fico feliz pela sua participação. Conheço sim o access e a versão que mais me marcou foi a 2.0 você lembra dela? A minha proposta é trazer para vocês uma nova visão que também não tem nada de novo e isso é importante que fique bem claro. Já falamos de ORM a muitos anos. Não sei se você é desenvolvedor ou dba. Você não precisa seguir nada que está escrito apenas agora sabe que existe um outro mundo. Banco de dados meu amigo é algo que devemos praticar o desapego. Em projetos de alta performance cara devemos no manter cada vez mais distante. Estamos falando em modos já não relacionais, caching e outros recursos para usar o mínimo possível. Olha para o facebook e veja se ele depende do banco de dados para computar um Like. Você inspirou a escrever a parte 2 desse post. Continue contribuindo e respeito a sua opinião ok? Somos amigos !!!

ronaldo

falar é facil,
agora ensinar o pessoal a fazer o negócio certo não é tão simples assim

Eu pelo menos, até hoje aprendi tudo que eu sei na raça, com grande ajuda de artigos na internet, e alguns livros

Os pouco programadores que conheci, eram na maioria arrogantes, e mesquinhos. Nenhum ensinou nada do que sabia. Nem um mínimo de ajuda eu tive. Eu vejo meus programas do passado, e penso, nossa quando eu aprendi aquilo, eu achava a coisa mais extraordinária do mundo, mas atualmente, eu evolui bastante, e aqueles coisas que antes me impressionavam, hoje são comuns para mim. Evolui como programador sim. Mas poderia ser um programador muito melhor, se outros programadores, parassem de ser mesquinhos, e ajudassem o próximo a evoluir também. No final, na minha opinião, todos ganham.

Eu leio vários artigos, e muitos falam: “Ahhhh mas como tem programdor, fazendo coisa da idade da pedra… AHHHHHH nem usar orientação a objeto sabe”.
Aprender sozinho não é fácil, mas as vezes nós ficamos rodando no mesmo assunto, e fazendo a coisa errada por muito tempo, pois não conseguimos enchergar a maneira correta de solucionar um problema.

Posso dar 2 exemplos muito bons sobre isso:

O primeiro eu encontrei quando eu li esse artigo. “Nossa a equipe de desenvolvimento está parada pois o dba tem que terminar de fazer as store procedures … e blablabla”. Porra meu, se os cara não sabem, vai lá e mostra como é que se faz. Ensina a equipe, ajuda os caras.

Outro dia li um artigo sobre .net de um rapaz muito conhecido no meio do .net, não vou citar nomes

No artigo ele falou sobre realizar uma conexão com o banco de dados, e eu lendo o artigo todo feliz, vendo ele usar o try catch finnaly. E eu achando que estava tudo correto, por que até onde eu sabia, fazer a conexão daquela maneira não tinha problema nenhum. Dai no final ele escreve assim “Pois é gente, quem sabe programar, sabe que fazer a conexão dessa maneira não está correto, ou melhor, não é o mais correto”

Porra meu, eu achava que daquele jeito era o mais correto, sempre fazia daquele jeito, ele vem e fala que não é o mais correto. Agora ensinar a solução mais correta, e profissional ele não quer…

Bom fica minha indignação, não li o artigo todo, por que já cansei de ler artigos assim. Metendo a lenha em nos desenvolvedores menos evoluídos que vocês.

    Ramon Durães

    Olá Ronaldo,
    Tudo bem
    Eu aprendi sozinho cara. Tenho uma enorme paixão pelo que faço e por isso dedico horas da minha vida conversando sobre esses temas. Antigamente as coisas demoravam muito para evoluir. Imagina que quando mudou do VB 3.0 para o VB 4.0 foi algo muito louco até entender a IDE e os novos conceitos. O ciclo hoje de tecnologia encurtou muito. Agora falamos em 2 anos. Você vai evoluindo a sua visão a medida que novas oportunidades de negócio forem demandando. Importante é você ter no radar os próximos passos a ir direcionando.

    Esse é um assunto muito polêmico. É só observar a reação nos comentários. É muito normal. Fique tranquilo e vamos construindo passo a passo.

Carlos Mattos

Parabéns pelo artigo Ramon! Sem dúvida é um assunto polêmico, e você abordou o tema de forma direta. Concordo com seu ponto de vista, tenho tentado quebrar esta resistência dentro das consultorias e projetos que tenho atuado. Mudar não é uma tarefa simples, nem tão pouco dolorosa, mas é fundamentalmente necessária. Grande abraço!

Rogério Moraes de Carvalho

Fala, Ramon!

Observe o seguinte trecho do seu texto: “É fácil você comprovar e verificar que todas as empresas que fizeram isso sofrem com gargalos nas operações de banco de dados que ficam travando registros eternamente”. Você fez a afirmação no contexto das empresas que adotam stored procedures e triggers. Pelo seu texto, basta o desenvolvedor usar ORM num sistema que não terá problemas com o “banco de dados travando registros eternamente”. Em sua opinião, o ORM é aquela solução de desenvolvimento que é capaz de fazer uma análise melhor que a de qualquer analista de dados, independente do contexto.

O certo é que uma boa solução num contexto pode ser péssima em outro. Não é possível fazer uma análise genérica e dizer que ela é a melhor solução independente de contexto.

Mas, vamos a um contexto concreto para que você possa sugerir uma implementação com uso de ORM (Code-First no Entity Framework, por exemplo), melhores práticas de POO e com as regras de negócios no servidor de aplicações como sendo uma melhor opção que o uso de stored procedures com regra de negócios no banco de dados.

Eu tenho um banco de dados com centenas de milhões de registros em algumas tabelas. Eu preciso gerar, em tempo real, um relatório de inconsistências nestes registros (centenas de milhões). Existe uma regra de negócios para filtrar tais inconsistências. Neste contexto, normalmente, o relatório de inconsistência gera um resultado com menos de uma centena de registros, podendo não trazer inconsistência alguma. Se eu adaptar o modelo de dados para as minhas necessidades, fizer stored procedures com a regra de negócios para encontrar tais inconsistências e criar índices para otimizar as minhas consultas, eu tenho como gerar o relatório de inconsistências em milésimos de segundo sem ter que trafegar centenas de milhões de registros do banco de dados para o servidor de aplicações. Somente os dados das inconsistências (normalmente, menos de uma centena de registros ou até nenhum registro) trafegariam do banco de dados para o servidor de aplicações.

Como você faria para gerar o mesmo relatório de inconsistências, em tempo real, com uma solução de ORM e as regras de negócios usando POO no servidor de aplicações? Você teria que levar centenas de milhões de registros do banco de dados para o servidor de aplicações, fazendo o mapeamento dos dados no banco para objetos na memória do servidor de aplicações, para aplicar as regras de negócios e encontrar as inconsistências. Você acha que conseguiria gerar o relatório em milésimos de segundos neste contexto? Ou eu estou pensando errado? Qual seria a sua solução neste contexto?

Abraços!

    Ramon Durães

    Olá Rogério,
    Tudo bem?
    Meu objetivo é provocar no leitor a possibilidade de pensar diferente em 99,99% dos projetos de software atuais com pensamentos legados criam ilhas de conhecimento esquecendo o prazer de fazer código limpo e integrado para que outras pessoas normais consigam manter e evoluir o negócio. Na impede de você comprar um ferrari e colocar combustível estragado vamos colocar o pé no chão e praticar o desapego. Eu compreendo que o assunto é forte mas com o tempo que vai passando vamos nos acostumando ok?
    Até a próxima!!!!

      Rogério Moraes de Carvalho

      Olá Ramon!

      Tudo ótimo comigo!

      Eu já desenvolvia com POO e ORM na plataforma Java em 2001, antes mesmo do lançamento da plataforma .NET em 2002. Não questiono as vantagens de se utilizar POO e ORM em diversos projetos de desenvolvimento de software, mesmo porque uso tais tecnologias há mais de uma década. O que eu não concordo é de você afirmar que esta sempre será a melhor solução sem contextualizar.

      Assim como você neste artigo, é impressionante como muitos profissionais do mundo da TI têm extrema facilidade para escrever artigos onde apresentam algumas tecnologias como soluções ideais para resolver todos os problemas de desenvolvimento, independente do contexto. Porém, estes mesmos profissionais são incapazes de analisar um contexto concreto e sugerir uma solução possível usando as tecnologias que defendem? Você preferiu fugir do contexto apresentado e comentar: “nada impede de você comprar uma ferrari e colocar combustível estragado”. Por que você não nos ensina a colocar o melhor combustível na ferrari no contexto apresentado?

      Abraços!

        Freitas

        Ramon Durães, os melhores bancos de dados tendem a acoplar a lógica de negócio ao armazenamento de dados e será se fazem isso só para aumentar a distância entre DBA e desenvolvedores? Tenho certeza que não, pois os melhores engenheiros de software e de banco de dados por meio das melhores práticas tornam determinados bancos de dados, e não tamboretes (cito access), padrão de mercado, a exemplo o Oracle. O próprio Access que você tanto fala mistura aplicação com banco de dados em um só arquivo. Penso eu que sua vivência e experiência reduzida fez que com que escrevesse esse artigo infeliz. Por que generalizar? Porque você não contextualizou conforme bem pontuou o Rogério Moraes? Que ainda hoje aguarda a resposta do melhor combustível para a Ferrari. Você fala como se fosse o guru da Informática, como se se soubesse de tudo e é isso que todos devem seguir, porque essa posição? Vamos descer do salto alto e sermos mais humilde nas opiniões. Trabalho em harmonia com vários desenvolvedores com regras de versionamento, permissões, lógica e tudo que se faz necessário para o desenvolvimento de um bom software. O que mais me parece é que pessoas como você acirram o ódio entre as equipes, portanto, não deveriam participar de projeto algum.

          Ramon Durães

          Caro Freitas,
          Exponha a sua opinião sem ofender o autor. Se deseja usar o banco de dados como uma camada de negócio da sua aplicação que faça . Você tem a liberdade de seguir os passos. Pelos comentários você trabalha como DBA? Compreenda que não desejo mudar o seu dia a dia. Apenas apresentei fatos da indústria ao longo dos últimos 15 anos. Acredito que os banco de dados estão preocupados com outras coisas muito além de ser repositórios de negócio. Desenvolvedores devem se focar em “Reuso de Software”. Fica a dica e até a próxima.

        Ramon Durães

        A melhor solução é entregar o seu projeto, permitir que outras pessoas consigam dar manutenção e reduzir o custo de operação acabando com a falsa produtividade que vem destruindo todos os projetos implementados nos últimos 10 anos. Só um sonho em uma página de um post resolver problemas de uma vida toda. Talvez você não compreenda a importância da mudança de atitude no desenvolvimento que desejo passar nesse artigo mas estou feliz em ajudar muitas outras pessoas. O mundo girou e quem desejar se conecta ou simplesmente ignora.

          Rogério Moraes de Carvalho

          Olá, Ramon!

          Não adianta nada você entregar o projeto, permitir que outras pessoas consigam dar manutenção e reduzir custos, se a solução entregue não satisfaz aos requisitos do sistema do seu cliente.

          Eu tentei debater tecnicamente com você, apresentando um contexto real, mas não tive sucesso. E entendo perfeitamente porque você ignorou o contexto apresentado em todas as suas respostas: simplesmente porque uma solução com ORM e POO não atende aos requisitos do sistema. Você não conseguirá gerar relatórios de inconsistências, em tempo real, trazendo centenas de milhões de registros do banco de dados para o servidor de aplicações, criando centenas de milhões de objetos na memória, para aplicar as regras de negócios usando POO. Fatalmente, as incosistências, se existirem, não serão geradas tão rapidamente usando uma mesma infraestrutura disponível.

          Tenho certeza que você compreendeu a situação apresentada, mas não consegue admitir que a sua tese não se aplica a qualquer contexto. Plagiando a sua última frase: “O mundo girou e quem desejar se conecta ou simplesmente ignora”.

Wilson Fernandes

Concordo com o Freitas e com Rogério M Carvalho.
Acredito que as regras devem ser agregadas e gerenciadas no banco afim de proporcionar uma melhor integração. A migração (a nível de aplicação) é muito mais simplificada, otimizando assim o tempo e os custos.
Na minha opinião, uma equipe com profissionais bem qualificados e selecionados fazem toda diferença. Incluo tanto DBAs como Developers. A falta de comprometimento (e conhecimento do negócio) entre os stakeholders envolvidos é que rebentam com um projeto ou um negócio.
Agora o que me deixou um pouco chateado foi esse trecho “De uma vez por todas, vamos deixar claro que quem entende de negócio é o cliente solicitante e o desenvolvedor que está construindo a aplicação”. Ora, por que excluir o DBA dessa discussão? Todos sabemos que entre a ideia e o produto final, muitas vezes, existe um abismo e, não acredito em desenvolvedores “sabe-tudo”. Deve sim haver uma comunicação limpa e sobretudo a aplicação das chamadas “melhores práticas”, evitando o “empura-empura” corriqueiro!
Talvez o relato do nosso amigo Ramon Durães se aplica em alguns cenários específicos, não devemos encarar como regra, vide outros cenários propostos “com uma solução de ORM e as regras de negócios usando POO no servidor de aplicações?”
Sustento que cada cenário haverá uma solução mais adequada, mas não posso dar um viés positivo ao texto do Ramon, pois há muitas discrepâncias em função da minha óptica.

Ramon Durães

Olá Wilson,
Tudo bem
Eu fico feliz com a sua opinião, mas discordo completamente da visão de acoplar a inteligência da aplicação ao banco de dados. Para isso usamos orientação a objetos senão ficará difícil para você escalar e manter o código da mesma. Nossa luta é justamente para organizar a inteligência da mesma favorecendo a reutilização e desculpa, mas banco de dados não é o local para isso. A grande confusão está justamente no entendimento do que é aplicação e o que é banco de dados independente de usar ORM ou não. Deixo a você a refletir. Não fique chateado comigo ok?
Até a próxima !!!

Roberto Capra

Olá Ramon,

Aqui você trouxe a tona mais uma das “velhas” discussões famosas da área: (Quem já tem mais de 15 anos de área e já viu isso em algum lugar levanta a mão!!! rsrsrsrsrs).
Entram tecnologias novas e saem, mas essa discussão arquitetural persiste. Pra falar a verdade, parabéns pois achei que foi bem ao tentar acordar parte de uma galera que pensa ser “SEMPRE” melhor optar por colocar “tudo no banco”. Só que infelizmente, o amigo pecou quando deu a entender (e eu que li tive essa impressão) de que entende que esse tipo de arquitetura é aplicável a qualquer contexto.
Acho que seria extremista demais pensar dessa forma…
O amigo deve concordar que há projetos que falhariam se fossem modelados assim e hoje, face aos recursos existentes no banco (falo tanto no Oracle quanto o SQL Server para citar exemplos conhecidos), usar o banco sempre como um mero repositório seria uma solução amplamente discutida por especialistas da melhor qualidade. E incluo aqui além dos DBAs, desenvolvedores com alguma experiência em banco de dados.

Acredito que é justamente por isso que deve haver equilíbrio ao analisar a melhor arquitetura, avaliando sempre os aspectos do escopo. Por exemplo, analisar os requisitos não funcionais e premissas que se tem é fundamental. Ex.: É um requisito de seu sistema possuir independência do banco de dados utilizado? É premissa que ele utilizará um já existente e não será migrado?.
A experiência nos mostra que isso varia de projeto para projeto, e se fosse para usarmos uma única régua, versões mais novas dos bancos de dados não trariam tais recursos (como procedures ou triggers), ou mesmo integração com OO e IDEs (como o próprio Visual Studio citado o faz).

Nem tudo é binário quando tratamos uma arquitetura sistêmica.

Mas essa é só minha humilde opinião…

Forte abraço.

Romulo Ribeiro

Tudo depende da regra de negócio. Utilizar ORM em alguns projetos com poucos dados trafegados entre o servidor de aplicação e o servidor de banco de dados é uma ótima opção, no entanto, em um projeto como citado pelo Rogério Moraes, utilizar o ORM fica inviável por causa da quantidade de dados, gerando uma demora desconfortável para o cliente. Minha opinião é que não existe forma de bolo para o desenvolvimento, precisamos sempre focar em entregar um produto leve, bonito e eficaz para o cliente.

Até mais.

Marcos Vinicios

Parabéns pelo artigo Ramon, muito bem descrito!
Att,

Qual a sua opinião?