Modelo em três camadas

Modelo em três camadas (3-Tier), derivado do modelo ‘n’ camadas, recebe esta denominação quando um sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado do cliente.

O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes.

Em contrapartida, o retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas que rodam na Internet ou em intranet e mais controle no crescimento do sistema.

As três partes de um ambiente modelo três camadas são:

Camada de Apresentação: É a chamada GUI (Graphical User Interface), ou simplesmente interface. Esta camada interage diretamente com o usuário, é através dela que são feitas as requisições como consultas, por exemplo.

Camada de Negócio: Também chamada de Lógica empresarial, Regras de negócio ou Funcionalidade. É nela que ficam as funções e regras de todo o negócio. Não existe uma interface para o usuário e seus dados são voláteis, ou seja, para que algum dado seja mantido deve ser utilizada a camada de dados.

Camada de Dados: A terceira camada é definida como o repositório das informações e as classes que a manipulam. Esta camada recebe as requisições da camada de negócios e seus métodos executam essas requisições em um banco de dados. Alterando o banco de dados alteraria apenas as classes da camada de dados, e o restante das camadas não seriam afetados por essa alteração.

Aplicações de uma camada (monolíticas): Nos tempos antigos do reinado do grande porte e do computador pessoal independente um aplicativo era desenvolvido para ser usado em uma única máquina.

Geralmente este aplicativo continha todas a funcionalidades em um único módulo gerado por uma grande quantidade de linhas de código e de manutenção nada fácil.

A entrada do usuário, verificação, lógica de negócio e acesso a banco de dados estava presente em um mesmo lugar. Podemos definir este tipo de aplicação como aplicação de uma camada ou monolítica.

Aplicações em duas camada: A necessidade de compartilhar a lógica de acesso a dados entre vários usuários simultâneos fez surgir as aplicações em duas camadas.

Nesta estrutura a base de dados foi colocada em uma máquina específica, separada das máquinas que executavam as aplicações.

Nesta abordagem temos aplicativos instalados em estações clientes contendo toda a lógica da aplicação (clientes ricos ou gordos).

Um grande problema neste modelo é o gerenciamento de versões pois para cada alteração os aplicativos precisam ser atualizados em todas as máquinas clientes.

Aplicações em três camadas: Com o advento da internet houve um movimento para separar a lógica de negócio da interface com o usuário.

A ideia é que os usuários da WEB possam acessar as mesmas aplicações sem ter que instalar estas aplicações em suas máquinas locais.

Como a lógica do aplicativo, inicialmente contida no cliente rico, não reside mais na máquina do usuário, este tipo de cliente passou a ser chamado de cliente pobre ou magro (Thin Client).

Neste modelo o aplicativo é movido para o Servidor e um navegador Web é usado como um cliente magro. O aplicativo é executado em servidores Web com os quais o navegador Web se comunica e gera o código HTML para ser exibido no cliente.

Neste modelo a lógica de apresentação esta separada em sua própria camada lógica e física. A separação em camadas lógicas torna os sistemas mais flexíveis permitindo que as partes possam ser alteradas de forma independente.

As funcionalidades da camada de negócio podem ser divididas em classes e essas classes podem ser agrupadas em pacotes ou componentes reduzindo as dependências entre as classes e pacotes; podem ser reutilizadas por diferentes partes do aplicativo e até por aplicativos diferentes.

O modelo de 3 camadas tornou-se a arquitetura padrão para sistemas corporativos com base na Web.

Resumindo, a camada de visão (view) é tudo que o usuário visualiza, o layout da página web ou de um sistema.

A camada de controle (controller) é onde temos os códigos Java, C#, PHP etc que organiza as informações vindas da camada de visão e grava na camada modelo (model) – banco de dados.

É possível manter a regra de negócio (onde é definido o que e como fazer) na camada controller ou model. Se deixarmos a regra no controller, é mais fácil migrar o banco de dados, se deixarmos a regra no model a migração da linguagem de programação é facilitada.

A decisão depende muito da empresa e de sua infraestrutura. Ambas as opções têm seus aspectos positivos e negativos.

Um contexto que força a mudança da regra de negócio é a saturação do servidor. Por exemplo, se o servidor de aplicação (camada controller) ficar saturado e o servidor de banco de dados (camada model) estiver subutilizado, é possível fazer a migração da regra até que os problemas no servidor de aplicação sejam resolvidos.

Também é possível fazer com que a camada de visão (view) mande todas as informações diretamente para a camada model, ignorando o controller. Isso é possível através do uso de procedures:

//Criamos as tabelas normalmente:
CREATE TABLE pessoa(
   idpessoa INT PRIMARY KEY IDENTITY,
   nome VARCHAR(50),
   sexo VARCHAR(1)
)
GO

CREATE TABLE telefone(
   idtelefone INT NOT NULL IDENTITY,
   tipo CHAR(3) NOT NULL CHECK(TIPO IN('cel', 'com')),
   numero CHAR(10) NOT NULL,
   id_pessoa INT
)
GO   

//Criamos a procedure recebendo parâmetros:
CREATE PROC cadastro @NOME VARCHAR(50), @SEXO CHAR(1), @NUMERO VARCHAR(10)
AS
   DECLARE @FK INT //Declaramos a chave estrangeira
   INSERT INTO pessoa VALUES(@NOME, @SEXO) //gera um ID
   
   //Pega o IDENTITY gerado na seção - chave estrangeira
   SET @FK = (SELECT idpessoa FROM pessoa WHERE idpessoa = @@IDENTITY)
   
   //Insere telefone na tabela de telefones
   INSERT INTO telefone VALUES (@TIPO, @NUMERO, @FK)
   GO

Para cadastrar:

cadastro 'João', 'm', 'cel', '995669999'
GO

Dúvidas ou sugestões? Deixem nos comentários! Para mais dicas, acesse o nosso canal no YouTube:
https://youtube.com/criandobits