Padrão Controller

Model-view-controller (MVC) é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afectam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.

O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interacção com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto.

Lida com o tratamento de mensagens ou eventos de sistema.

Atribuir a responsabilidade de tratar eventos do sistema a uma classe que representeuma das seguintes opções:

▪Representa o sistema como um todo, um dispositivo ou um subsistema (umcontrolador fachada);
▪Representa um caso de uso em que o evento de sistema ocorre (controlador de casode uso ou sessão).

A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação.
A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário.
Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.

Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados.
O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.

Vantagens do modelo MVC :

Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
Torna a aplicação escalável
É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.

Desvantangens do modelo MVC:

Requer uma quantidade maior de tempo para analizar e modelar o sistema
Requer pessoal especializado
Não é aconselhável para pequenas aplicações

Acoplamento de Controle

Um controlador é um objeto responsável por tratar um evento de sistema (caso de uso), mas que pertence à camada de domínio.

Problema:
Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?

Solução:
Uma classe que representa uma das seguintes opções:

– Representa o ”sistema”, todo o negócio ou organização (Controlador fachada);
– Representa todo o negócio e
– Representa algo do mundo real que é ativo e envolvido na tarefa (Controlador de papel);
– Representa um “tratador artificial” dos eventos de sistema de um caso de uso (Controlador de caso de uso)

O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.

Existem duas alternativas possíveis para o objeto controlador:

- Um objeto Controlador para todo o sistema
- Um objeto Controlador por Caso de Uso

Os benefícios do padrão controlador são:
--- Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio
--- Oportunidade para controlar o estado do caso de uso.

» Evita que objetos da camada apresentação tratem as operações do sistema;
» Aumenta o potencial de reutilização;
» Possibilita o controle de seqüência de operações do sistema.

Padrão Baixo Acoplamento:


O padrão baixo acomplamento tem como objetivo a redução e miniminização da conexão de um objeto com outros. Esta conexão esta relacionada a ter conhecimento sobre os outros objetos ou simplemente depender de outros objetos. De forma sujacente manter o acoplamento baixo significa redizir o impacto de mudança já que ao se alterar um objeto um mínimo de outros objetos serão afetados.

Problema: Como aumentar independência dos objetos de forma a possibilitar a sua reutilização?

Solução: Atribuindo responsabilidades de maneira que o acoplamento permaneça fraco.


Resulta num acoplamento geral mais fraco entre as classes:

»Resulta em classes mais independentes;
»Reduz o impacto de mudanças;
»Aumenta o potencial de reutilização;
»Não deve ser utilizado isolado dos outros padrões.

public class Produto
{
private integer idProduto;
private string descrição;
private double valorUnitário;

public string getdescrição(){
return dscrição;
} public void setDescrição(string valor)
{ descrição=valor;
}

public class ItemVenda {
private double qtde;
private Produto p;

public void setP (Produto p) {
this.p = p;
}

public class Venda {
private Set itemVendaLiat=new HashSet();
private Date dataVenda;
private integer idvenda;
public criar Itemvenda (Produto P, double qtde)
{
Itemvenda i =new ItemVenda();
i.setP(p);
i.setQtde(qtde);
itemVendaList.add(i);
}

Atribui à classe "A" a responsabilidade de instanciar a classe B caso algumas destas condições sejam verdadeiras (quanto mais alternativas sejam verdadeiras melhor).