Não Faça Regras de Negócio Dentro do SGDB

240px-Stop_hand_nuvola.svgJá se passaram muitos anos desde a década de 90 e ainda assim eu continuo ouvindo e vendo muitas corporações colocando regra de negócio das soluções dentro de um banco de dados. Hoje o cenário de soluções corporativo é outro completamente mais complexo e a arquitetura em duas camadas não oferece características que sustente sua evolução. Resumidamente, soluções construídas em duas camadas não cumprem requisitos como escalabilidade, extensibilidade, manutenibilidade, segurança, perfomance e disponibilidade. Dessa forma, hoje usamos arquitetura n-camadas que é a única que, se bem projetada pode cumprir todos os requisitos não-funcionais característicos das soluções atuais. Segue um resumo básico dos velhos e já batido motivos documentados que justificam o não uso de regras dentro de um banco de dados:

1. Acoplamento

Regra dentro do banco de dados viola o princípio SOC que define que cada pedaço de um sistema precisa estar localizado em um lugar único e exclusivo promovendo isolamento, manutenção, reutilização e futura substituição, sem impacto nas outras partes.

2. Falta de Portabilidade

Regras escritas dentro do banco não oferecem portabilidade entre os diferentes produtos concorrentes da mesma filosofia de banco de dados adotado. Na década de 90 já era um transtorno e só tínhamos os famosos SGDB. Hoje então a coisa piorou com o surgimento com NoSQL e suas varias opções estruturais.

3. Péssima Manutenção e Código Inflexível

Regras no banco de dados são na maioria das vezes escritas usando store procedures  (filosofia procedural da década de 60) que são desprovidos de recursos e as diretrizes da OOP como encapsulamento, agregação, composição, associação, herança e polimorfismo e da mesma forma não conseguem usufruir de nenhum tipo de padrões (Patterns) arquiteturais, projetos e programação.

4. Know-How Especializado

Regras no banco de dados precisam ser manutenidas por profissionais que detenham conhecimento especializado para aquele particular produto e filosofia de banco de dados adotado, sendo difícil e ou caro de se encontrar mercado ou de se formar internamente.

5. Problemas de Performance

Soluções de grande porte, dotadas de um grande e crescente numero de acessos simultâneos e com a execução de regras pesadas vão degradando gradativamente a performance da solução, podendo até (que é o acontece na maioria dos casos) derrubar o serviço, uma vez que os banco de dados são desprovidos de devidos gerenciamentos de recursos encontrados normalmente em MIDDLEWARE relacionados com técnicas de otimizações, tunning, comunicação assíncronas, mensageira (MOM), escalabilidade vertical e horizontal apropriadas aplicadas especificamente na execução das regras de negócios.

6. Ausência de Recursos

Regras de negócio corporativas normalmente englobam o uso de recursos como logica binária, manipulação de arquivos PDF, DOC, XLS, XML, JSON.  Comunicação com sistemas externos como LDAP, SMTP, FTP, Mensageira, SOAP, REST etc. Os SGDB normalmente não possuem API’s disponíveis para estes fins e muitos outros recursos, salvo em casos raros que alguns provedores de SGDB fornece alguma coisa bem limitada e proprietária para tratar um ou outro. A coisa piora por que normalmente não existe abertura para se acrescentar uma API de terceiros para dentro do banco.

Conclusão

Martin Folwer no livro Patterns of Enterprise Application Architecture capitulo 8 escreveu:

“Por todas estas questões, muitas pessoas evitam implementar regras de negócio dentro de um banco de dados. Eu tento me alinhar com esta visão a menos que haja um grande ganho de desempenho a ser obtido, o que, para ser sincero frequentemente ocorre. Nesse caso, pego um método de negócio da camada de domínio e, alegremente  o transformo em um procedure dentro de um banco de dados. Faço isso apenas em áreas com claro problemas de desempenho, tratando-o como um abordagem de otimização e não como um principio arquitetural.”

Joshua Bloch no livro Java Effective capítulo escreveu no item 55 (que eu resumi):

“A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de profile e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.”

Acredito que todos estes fatos já fornecem base suficiente para que você tenha condições de fazer a sua tomada de decisão :D . Até a próxima!

“Quão grande és tu, ó Soberano SENHOR! Não há ninguém como tu, nem há outro Deus além de ti, conforme tudo o que sabemos.” 2 Samuel 7:22

Aprenda o Escopo Thread-Local

Dentro da programação de uma solução usando a tecnologia Java, os desenvolvedores tem a responsabilidade diária de escolher corretamente em qual escopo de ciclo de vida seus objetos existiram. Em minhas consultorias em geral venho percebendo que a maioria dos profissionais Java desconhecem completamente um dos escopos mais interessantes e muito eficiente chamado de Thread-Local. A falta de uso desse escopo em uma solução pode gerar complicadores agravantes na arquitetura, levando a implementação na maioria das vezes para o caminho da complexidade e inflexibilidade. Diante esse cenário, hoje eu gostaria de apresentar o conceito e prática desse escopo, fazendo com que programadores e projetistas Java possam se equipar com mais esse poderoso recurso do JSE.

O que é Thread-Local?

Thread-local é considerado como mais um “escopo de acesso” como outros muitos existentes dentro do Java utilizado para definir o ciclo de vida dos objetos existentes durante a execução de um programa orientado a objetos. O grande diferencial desse escopo seja talvez pelo fato dele ser completamente baseado em conceitos de programação concorrente, fazendo com ele fique um pouco mais complicado de se entender e usar.

Como funciona?

O escopo Thread-Local possui dois tipos de comportamento distintos que lhe diferencia drasticamente dos outros. Poderíamos chamá-los de global e local.

Global – todos os objetos armazenados em uma Thread-Local são globais para a thread corrente de execução. Isso que dizer que os métodos de quaisquer objetos sendo executados dentro de uma mesma thread terão visibilidade para este escopo.

Local – todos os objetos armazenados em uma Thread-Local estarão restritos somente para objetos sendo executado dentro da determinada thread. Isso que dizer que os métodos de quaisquer objetos sendo executados em outras threads não terão visibilidade para este escopo.

O ponto de referencia para se assimilar a brincadeira é se conscientizar que quem executa um método de um objeto dentro de um programa Java é justamente algum objeto Thread, sendo ele criando manualmente ou não. Dentro de cada thread existe então um lugar especial que pode ser usado para armazenar objetos pertencentes especificamente a thread. Todos as chamadas de objetos que forem empilhados naquela thread terão visibilidade transparente para esse escopo, podendo então usa-lo para os mais diferentes propósitos.

Para tentar clarear mais as idéias, eu poderia dizer que o escopo Thread-Local funciona basicamente da mesma forma que o famoso e velho de guerra escopo estático. Todos os objetos colocados como estáticos no Java são criados apenas uma vez e ficam na memória até o termino da JVM. A única diferença é que os objetos colocados na Thread-Local ficam na memória até o termino da execução da determinada thread corrente. O escopo acaba, quando a Thread terminar de ser executada.

A figura abaixo apresenta um gráfico que ilustra a escopo estático:

Temos na figura acima dois objetos do tipo thread invocando concorrentemente métodos de alguns objetos compartilhados e outros objetos não compartilhados. Tudo que é colocado como estático é globalmente compartilhado para todas as threads e todos os objetos sendo executados dentro de cada thread.

Já na próxima figura temos a representação que ilustra o escopo Thread-Local:

Temos na ultima figura dois objetos do tipo thread invocando concorrentemente os mesmo objetos da primeira figura. Nesse caso em especifico, o escopo Thread-Local age como um compartimento opcional colocado dentro da cada thread, no qual todos os métodos invocados dentro daquela determinada thread tem acesso transparente, podendo usá-lo para qualquer fim necessário.

Quando usar Thread-Local

Use em qualquer lugar que necessite compartilhar objetos em nível de execução de Thread. Alguns possíveis exemplos seriam – parâmetros de sistema, parâmetros de usuários, parâmetros de autenticação e autorização e até parâmetros de processos. Um caso clássico de Thread-Local é a propagação de objetos de transação JDBC com chamadas recursivas. Objetos do padrão DAO poderiam usar este escopo para compartilhar a transação corrente, adicionando varias instruções SQL de diferentes objetos DAO. Frameworks que oferecem serviços transacionais para camadas de persistência como Spring utilizam-se dessa abordagem, podendo também ser facilmente implementada sem nenhum framework de terceiro.

A escopo Thread-Local é disponibilizado no Java usando a classe java.lang.ThreadLocal. Para todas as informações dessa classe, veja o JavaDoc.

Prática

Segue abaixo a implementação de um exemplo bem simples de Thread-Local.

A primeira classe chamada de ClasseThreadLocal foi utilizada para implementar a escopo Thread-Local. A segunda classe chamada de Regra foi utilizado para implementar o objeto que será executando concorrentemente dentro de varias threads. Veja que o método gravar() apenas acessa o valor dentro do escopo Thread-Local. Já a classe ProcessoThread  foi utilizado para implementar as threads que serão executadas em paralelo. Veja que o método run() armazena um objeto do tipo String dentro do escopo Thread-Local que será posteriormente acessível dentro do objeto implementado pela classe Regra. Por fim vemos a classe Exemplo implementando a método main() que faz toda a brincadeira acontecer. Veja que ele cria apenas um objeto Regra e quatro objeto ProcessoThread. Resumidamente, cada objeto thread executa concorrentemente o mesmo objeto Regra que transparentemente e separadamente acessa cada um valor diferente pertencente a sua própria thread de execução.

Observação

Existe uma certa situação em usar Thread-Local dentro de containers JEE, uma vez que a maioria deles otimizam gatos com a criação de objetos threads usando abordagem de pool. Por isso, os objetos colocados dentro do escopo Thread-Local em execuções dentro de containers JEE podem ficar não elegíveis para o GC após a execução, uma vez a thread volta para o pool e fica disponível para a próxima invocação. A forma correta de tratar isso é limpar o escopo Thread-Local no final de cada execução, chamando o método ThreadLocal.remove(). Eu fico por aqui e espero que o artigo te ajude a usar esse incrível escopo. Aquele abraço ;) .

“Porque, se perdoardes aos homens as suas ofensas, também vosso Pai celestial vos perdoará a vós”. Mateus 6:14

Curso de Java Básico Inicial – JSE M1

grande

“Por isso, também (Jesus) pode salvar totalmente os que por ele se chegam a Deus, vivendo sempre para interceder por eles.” Hebreus 7:25

Java Frameworks – JavaServer Faces

jsf-logo-squareSegue opções para framework de componentes visuais para o desenvolvimento de soluções web com JSF:

Provedores de JSF

 Componentes JSF

Extensões JSF

Para todas as informações, veja o post inicial.

“Como está escrito: Por minha vida, diz o Senhor, diante de mim se dobrará todo joelho, e toda língua dará louvores a Deus.” Romanos 14:11

Feliz Dia Do Programador

promocao-dia-programador

Quero desejar um feliz dia do programador para todos!!!

“Entrega o teu caminho ao Senhor; confia nele, e ele tudo fará.” Salmo 37.5

MOB M2 – Desenvolvimento Web Mobile – Belagricola 09/09/14

curso

MOB M2 – Desenvolvimento Web Mobile

“Onde está, ó morte, a tua vitória? Onde está, ó morte, o teu aguilhão?O aguilhão da morte é o pecado, e a força do pecado é a lei. Graças a Deus, que nos dá a vitória por intermédio de nosso Senhor Jesus Cristo.” 1 Coríntios 15:55-57

Curso Web Mobile – Início Sábado 13/09

Mobile - Cópia

Treinamento Mobile Web – JQueryMobile Básico

Atenção

Este curso tem o objetivo de cobrir técnicas e estratégias exclusivas para FRONT-END, não abordando nenhum tipo de tecnologia de BACK-END. Ou seja, isso quer dizer que durante esse curso sera abordado a criação de interfaces gráficas focadas para mobile sem utilização de tecnologia ou plataforma de server side.

“Se, com a tua boca, confessares Jesus como Senhor e, em teu coração, creres que Deus o ressuscitou dentre os mortos, serás salvo. Porque com o coração se crê para justiça e com a boca se confessa a respeito da salvação.” Romanos 10:9-10

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 670 outros seguidores