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
Quer receber GRÁTIS o e-book "Como Formatar um Computador em 5 Minutos"?
Sobre o Autor
0 Comentários