Trabalhando em Camadas

A divisão da aplicação em camadas é uma técnica muito utilizada e difundida pelos projectistas de software e que usualmente pode ser útil para projectos de médio a grande porte. A pensar na sua utilidade podemos destacar:

• Facilidade de implementação: Podemos bem escrever um serviço que consumirá dados oriundos de uma base de dados qualquer sem conhecer necessariamente sua estrutura, assim como, podemos modificar a base de dados sem que nosso serviço seja alterado;
• Reutilização de código: Uma vez construído nosso serviço, o mesmo poderá ser usado em alto nível pelos clientes que o consumirão em outras aplicações.

Esses factores são relevantes mas não podemos esquecer que há também aspectos negativos na utilização de camadas como:

• Alterações em cascata: As camadas encapsulam muito do desenvolvimento, mas por vezes uma simples alteração implica em alterações em toda a estrutura acoplada. Para o caso de uma adição de uma coluna no banco de dados a camada lógica seria alterada, nosso serviço também o seria se o mesmo actuasse como “Objecto Valor” para persistência de informações e por conseguinte os clientes consumidores também o seriam;
• Desempenho: Abstracção para uso em camadas tem um custo no factor desempenho, que muitas vezes é crucial para determinadas áreas do projecto.

Para atenuar os pontos-contra desta técnica convém:

• Usar Baixo Acoplamento: Já que as camadas estarão aninhadas, melhor que seja somente pelos seus dados referentes, Camadas acopladas em alto nível de dependência directa deverão ter suas dependências exportadas para outros projectos, dificultando assim a reutilização de código e alterações em cascata de mais do que se deve alterar;
• Não ser um projectista purista: O modelo de projecto divido em camadas é bom, mas não é uma verdade absoluta. Negócios requerem desempenho e em áreas onde a curva de desempenho cai é necessário buscar estruturas menos custosas, um Proxy (Proxy GoF) é uma boa saída se você precisa de instâncias de memórias constantes de áreas críticas, contudo, na maioria das vezes é necessário buscar estruturas de dados mais rápidas, e envolvê-las em um Adaptador (Adapter GoF).

Cabe salientar que padrões, quaisquer que sejam, demonstram imperfeição no paradigma que é utilizado, ou que o mesmo não é completo, o que por si só gera um conceito mais abrangente que foge do escopo deste artigo.

A estrutura mínima de funcionamento

A estrutura mínima de funcionamento corresponde às seguintes camadas:

• Apresentação: Camada onde os dados são visualizados e alterados pelo usuário, nessa camada fica toda a experiência do usuário com o que ele tem como sendo o software;
• Domínio: Modelo de negócio, aqui é o local ideal para mantermos representações lógicas do nosso modelo de dados e todo comportamento inerente a ele;
• Modelo de Dados: Aqui está nosso repositório de dados, geralmente representação física de um banco de dados.

Convém alertar para que não confundamos estas camadas base com o difundido MVC, (Model, View, Controller). Uma estrutura MVC, se utilizada, estaria entre o Domínio (que corresponde ao Model) e a Apresentação (correspondente a View) tendo o Controle da Aplicação (Controller) entre elas.

É plausível que estas camadas podem ser estendidas de acordo com a necessidade sumária do projecto, mas devemos ter cuidado para não ferir a utilidade do modelo que estamos criando. Um bom medidor para tal seria analisar uma interface de apresentação totalmente imprópria para o modelo original, como uma aplicação de linha de comando para um comércio electrónico. Se ainda assim essa implementação parecer viável no modelo actual é um provável indicador que sua arquitectura vai bem.

Organização do Domínio

Então, como organizar o modelo de dados? Há algumas maneiras dentre as quais destacam-se:

• Modelo Procedimental: De fácil implementação pela sua simplicidade, funciona bem quando se tem como acesso uma estrutura fazendo o papel de gateway por cada tupla ou em estruturas desconectadas multi valoradas. O aspecto negativo é que é fácil ter código duplicado a partir do momento que o cenário passa a requerer lógica mais complexa. Essa duplicidade pode ser revista, mas ainda assim é fácil ter código virulento;
• Modelo de Domínio: A “mudança de paradigma” que os projectistas que saltaram para o mundo OO tanto falam parece nascer aqui. Em um modelo de domínio para um sistema de comércio electrónico, por exemplo, seria pertinente ter classes para clientes, produtos, tributações, arredondamentos, internacionalização, etc. Esta abordagem super valora o modelo, contudo, acentua a curva de aprendizagem. É comum ver projectistas trabalhando meses em projectos pequenos ou médios para habituar-se a tal modelo. Outra dificuldade inerente desse modelo é a persistência do seu modelo de domínio. Um modelo de domínio rico tende a ser bem diferente do modelo relacional disposto na sua camada de dados, o que implica em complexidade na persistência com gateways de dados e a provável necessidade de uso de uma camada adicional para realizar o mapeamento objecto relacional;
• Módulo tabela desconectado: Este é um intermédio entre as duas maneiras. Organizar os dados em estruturas desconectadas que representem tabelas alivia a repetição desnecessária de escrita das operações CRUD, além do que, possibilita o uso dos conceitos OO neste mesmo modelo. Outro factor implicante é que a maioria dos ambientes corporativos reluta em adoptar uma camada de dados orientada a objectos devido a instabilidade e relativa imaturidade dos produtos comerciais para tal fim existentes, comparando os mesmos a bancos de dados relacionais. Além disso várias ferramentas comerciais tendem a utilizar conceitos de objectos e estruturas desconectadas, o que, facilita a utilização deste modelo com tais ferramentas; Porém esse modelo só tem tais facilidades de uso em ambientes projectados para isso, com frameworks e bibliotecas para trabalhar com tais estruturas.

Cada modelo tem seus aspectos que o favorecem ou não. Cabe a nós projectistas ante o problema, a experiência da equipa, os factores de tempo, recursos e retorno provável sobre o investimento, avaliar e escolher a melhor forma de organizar a lógica de um projecto organizados em camadas.

Não ser extremista nas suas concepções, ouvir e valorizar as ideias de cada um da sua equipa, estudar e contar com erros e acertos do passado, o ajudarão a não tropeçar no alvoroço que entorna a arquitectura de software e ter projectos realmente escaláveis utilizando com sapiência cada recurso tecnológico disponível.