"É na mudança que encontramos propósito."
Heráclito
Após uma lacuna de 3 anos, cá estou eu. Por questões ligadas a minha vida pessoal e profissional, não pude continuar com o blog, reassumindo, agora, seu andamento. Peço desculpas a todos aqueles que acompanharam o blog, esperando mais artigos ou novidades, mas realmente não foi possível para mim.
Mas, enfim, vamos ao que interessa.
O contexto
Atuando no mercado de desenvolvimento de software há vários anos, nas mais diversas situações com as mais diversas soluções, sempre me deparava com um problema comum a todas: a impossibilidade da centralização do processamento. Como é comum no mercado brasileiro de software, muitas empresas basearam seu desenvolvimento no paradigma de desenvolvimento Cliente/Servidor, onde a própria aplicação utilizada pelo usuário geria suas regras de negócio, fazia o acesso ao banco de dados, obtinha, manipulava e persistia os dados do sistema. Em pequenas aplicações este paradigma não se mostra tão problemático. O problema se apresenta, e de maneira muito intensa, quando aquele projeto pequeno começa a crescer, principalmente, sem planejamento. Apesar de parecer absurdo, isto é muito mais comum do que parece.
O problema
Quando planejamos uma aplicação, devemos ter em mente que, independente do público alvo inicial, uma aplicação deve estar preparada para atender, mesmo que em um único segmento, clientes que podem ir desde um único terminal, com um único usuário, até grupos empresariais, com dezenas ou centenas de filiais. Para atender este segundo cenário, as empresas geralmente, por possuírem aplicações construídas em apenas 2 camadas, utilizam a conexão direta ao banco de dados através de redes de alta latência (aka Internet), ou, o que considero a menos eficiente das soluções, a replicação em lotes da informação entre vários servidores de bancos de dados, os quais também utilizarão redes de alta latência para isso.
Como a maioria das empresas opta por soluções de banco de dados gratuitas, principalmente Firebird, o cenário se complica ainda mais. Alguns servidores de bancos de dados, por possuírem protocolos mal estruturados, e cito mais uma vez o Firebird, seu desempenho em redes que não sejam locais torna-se, realmente, sofrível. Como pude perceber ao longo de todos este anos, muitas empresas pequenas de software, e até mesmo algumas médias e outras grandes, nasceram do casamento de dois fatores comuns a todas elas: muita força de vontade e nenhum conhecimento técnico. E isso tem feito com que ferramentas disponíveis há vários anos no mercado sejam incapazes de atender demandas simples, como uma segunda unidade de uma empresa, em um local afastado e com pouca oferta de conectividade com a internet. Além das duas "soluções" apresentadas anteriormente, as empresas utilizam-se do famigerado Windows Terminal Service - o famoso TS - para que seja possível a integração entre as unidades e possibilitar a centralização do processamento e armazenamento de dados.
As desvantagens do modelo Cliente/Servidor
As desvantagens em utilizar qualquer uma destas soluções são inúmeras: alta latência e desempenho geral da aplicação altamente prejudicado, possibilidade de inconsistência de informações, falhas de replicação, elevados custos em infraestrutura para atender a virtualização de terminais, etc. Isso, ainda, sem citar a falta se segurança dos protocolos de bancos de dados que podem fazer com que dados críticos trafeguem como texto plano pela rede.
Esta última situação pode ser contornada adicionando à comunicação protocolos de criptografia e compressão providos por outros componentes de software. Isso resolve o problema de segurança, mas traz mais um empecilho: este componente adicionado à comunicação implica, obviamente, em uma carga extra de processamento em ambas as pontas desta comunicação. Alguns dirão: "mas com os computadores atuais, esta carga adicional pode ser desprezível". Sim, talvez, mas dependendo da latência da rede, mesmo comprimido e criptografado, ambas as pontas podem enfrentar problemas com o protocolo de comunicação.
Outra grande desvantagem do desenvolvimento Cliente/Servidor está, acreditem, nos próprios programadores. Muitos programadores que utilizam Object Pascal, por possuírem IDEs RAD, estão tremendamente acostumados a arrastar componentes, acessar seus eventos e escrever as regras de negócio dentro deles. Isso faz com que, ao invés de cumprir apenas o seu papel, que é receber e exibir dados, a interface com o usuário também controle as regras de negócio da aplicação. Com isso, e usando uma extrapolação simples, se um ou mais formulários controlarem a mesma regra de negócio e esta estiver replicada em cada um deles, a manutenção em um único ponto não garante que esta manutenção seja replicada em cada um dos formulários, gerando divergências entre as regras.
E, por fim, aplicações Cliente/Servidor possuem um baixo índice de integrabilidade, fazendo com que integrações com outras aplicações sejam custosas e, na sua imensa maioria, constituídas de uma série de gambiarras artifícios técnicos dispensados para solução e/ou atendimento de necessidades levantadas segundo preceitos de engenharia de contorno. Isso faz com que a aplicação integrada tenha uma regra específica para processar as informações que serão entregues à aplicação integradora, o que pode, por falha no desenvolvimento da regra em uma das pontas, gerar divergências e erros na outra.
O modelo multicamadas
Visando resolver este problema, alguns malucos cientistas dos laboratórios da Xerox, durante o desenvolvimento do projeto Smalltalk, criaram um modelo de análise e desenvolvimento que, até hoje, se mostra muito eficiente e que permite que vários componentes de software interajam entre si: o modelo multicamadas. Este modelo estabelece que, para que um projeto seja eficiente e possua um baixo custo de manutenção e alta manutenabilidade, suas regras de negócios devem, sempre, ficar isoladas da interface com o usuário, de modo a não interferir em sua usabilidade, e garantir a unificação do processamento dos dados relativos à aplicação. Estas regras, ainda, deveriam estar igualmente isoladas dos dados a serem inseridos, manipulados ou persistidos, acoplando-se a eles o mínimo possível.
Alguns podem ter notado uma nítida semelhança com a arquitetura MVC (Model View Controler), também criada durante o desenvolvimento do Smalltalk, pois de fato ela existe, mas é preciso entender que estes conceitos não implicam, necessariamente, em uma unanimidade. Planejar e construir um software sob a arquitetura MVC não implica em um desenvolvimento multicamadas (como pode ser visto no desenvolvimento web com PHP ou Java), assim como desenvolvimento multicamadas não está limitado ao modelo imposto pela arquitetura MVC.
O planejamento e desenvolvimento de aplicações multicamadas resolvem, por si só, todos os problemas que o desenvolvimento Cliente/Servidor pode trazer: unifica as regras de negócio em apenas um ponto, estabelece um protocolo de comunicação mais enxuto e leve, ideal para redes de alta latência, dá a possibilidade da utilização de interfaces com o usuário em múltiplas plataformas, reduz os custos de manutenção da aplicação como um todo, aumenta sua manutenabilidade e, por consequência, seu ciclo de vida, etc. Ou seja, planejar e desenvolver aplicações em múltiplas camadas agrega à própria aplicação uma gama infinita de possibilidades.
Quando necessário, aplicações diversas podem, da maneira convier a seus desenvolvedores, integrar-se a aplicações desenvolvidas sob esta arquitetura, sem a necessidade da criação de regras específicas para a esta integração. Aplicações multicamadas geralmente têm, para facilitar este processo, métodos públicos que serão utilizados para estes fins, mantendo as regras de negócio apenas na aplicação integradora, sem que a aplicação integrada tenha que inteirar-se de suas particularidades em seu desenvolvimento.
Enfim, o modelo de desenvolvimento multicamadas se mostra infinitamente superior ao modelo Cliente/Servidor pois possibilita, ao mesmo tempo, um ganho relativamente alto de performance em cenários críticos como a possibilidade da expansão dos horizontes da própria aplicação, que pode atender desde a menor das demandas até aquelas em que o modelo de 2 camadas é incapaz de atender.
