MVC padrões arquiteturais

Padrões Arquiteturais

Sistemas Interativos:
MVC

Sistemas Interativos
• Sistemas atuais apresentam alto grau de
interação do usuário
• Desafio: independência do núcleo
funcional (estável) da interface do usuário
(adaptáveis)
– MVC
– PAC: hierarquia de agentes cooperantes.
Cada um deles é responsável por um aspecto
da funcionalidade da aplicação.
2 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari
Architecture - Buschmann

Model-View-Controller
• Divide uma aplicação interativa em 3
componentes:
– Model: contém o cerne da aplicação e os dados
– View: mostra a informação para o usuário
– Controller: trata a entrada do usuário
• Juntos, Views e Controllers fazem a interface com o
usuário
• Deve haver um mecanismo de propagação de
mudanças para assegurar a consistência entre a
interface e o modelo

Exemplo


Contexto
• Aplicações interativas com uma interface
homem-computador flexível


Problema
• Sist. interativos são propensos a mundanças
– Dif. usuários colocam diferentes requisitos
• Mesma informação pode ter que ser
apresentada de forma diferente em diferentes
janelas
• A visualização e o comportamento da aplicação
devem refletir imediatamente os dados
manipulados
• Mudanças na interface devem ser fáceis e
possivelmente em tempo de execução
• Suportar diferentes padrões de aparência não
devem afetar o código do núcleo da aplicação

Solução
• MVC divide uma aplicação interativa em 3
áreas: processamento, saída e entrada
– Componente MODEL: encapsula os dados do núcleo
da aplicação e sua funcionalidade
– Componentes VIEW: mostra as informações para o
usuário. Obtém-nas do MODEL
– Cada componente VIEW tem um componente
CONTROLLER associado
• Recebem a entrada (usualmente eventos)
• Eventos são traduzidos em requisições de serviços que são
enviadas para o MODEL ou para VIEW
• O usuário interage com o sistema apenas através dos
CONTROLLERs


Solução
• Esta separação possibilita múltiplas visões
do mesmo modelo
• Usuário modifica Model via Controller de
um View
– Model notifica todos os Views dependentes
destes dados
– Views, por sua vez, recuperam dados do
Model e atualizam a informação para usuário


Estrutura
• Model
– exporta procedimentos que realizam
processamento específico da aplicação
• Controllers chamam estes procedimentos em
nome do usuário
– Provê funções para acesso a seus dados
• Usadas pelos Views
– Usa mecanismo de propagação de mudanças
• Views e Controllers se registram


Estrutura
• Views
– Cada View define um procedimento de
atualização (ativado pelo mecanismo de
propagação de mudanças)
– Uma vez notificado, obtém dados atuais e os
atualiza na saída
– Cada View cria um Controller adequado (1:1)
– Provê funcionalidades de manipulação da
saída ao Controller que não afetam o Model
(p.ex., scrolling)

Estrutura
• Controller
– Aceita entradas como eventos (depende da
plataforma da interface)
– Eventos são traduzidos em requisições ao
Model ou ao correspondente View
– Se o comportamento do Controller depende
do estado do Model
• Controller se registra no mecanismo de
propagação de mudança e implementa um
procedimento de atualização (ex., habilitar ou
desabilitar um menu)

Estrutura


Dinâmica – Cenário 1
Entrada do usuário  trigger MPM

*


Cenário 2 – Inicialização
da tríade MVC


Implementação
1. Separar a interface Homem-Máquina do
núcleo funcional
class Model{ / / factory functions for view access to
data
List<long> votes;
Iterator<long> makevoteIterator( ) {
List<String> parties;
return Iterator<long> (votes);
public :
}
Model(List<String> partyNames);
Iterator<String> makePartyIterator( )
{
// access interface for modification by
controller return Iterator<String>(parties);
void clearVotes(); // set voting }
values to 0
void changeVote(String // ... to be continued
party, long vote); }


Implementação
2. Implementar o mecanismo de
propagação de mudança
• Padrão de Projeto Publisher-Subscriber
• Estender Model para suportar o registro
• Procedimento notificador do Model deve
chamar procedimento de update nos objetos
Observer


Implementação
class Observer { // common ancestor for view and controller
public :
virtual void update( ) { }
// default is no-op
};

class Model {
// ... continued
public :
void attach(Observer *s) { registry.add (s) ; }
void detach (Observer *s) { registry. remove (s) ; }
protected :
virtual void notify( );
private :
Set<Observer*> registry;
};

Implementação
void Model::notify ( ) {
// call update for all observers
Iterator<Observer*> iter(registry) ;
while (iter.next()) {
iter.curr( )->update ( );
}
}

- notify() é chamado pelos métodos clearVotes() e
changeVote()


Implementação
3. Projetar e Implementar os Views
• Especificar os proced. (draw) para mostrar o
componente na tela
• Impl. proced. de update (re-draw)
• Impl. proced. de inicialização (registro, setup
do Controller)
class View : public Observer (
public:
View (Model *m) : myModel (m) , mycontroller (0)
{ myModel ->attach(this) ; }
virtual ~View ( ) ( myModel ->detach (this) ; }
virtual void update ( ) { this->draw 0 ; }

Implementação
// abstract interface to be redefined:
virtual void initialize( ) ; // see below
virtual void draw ( ) ; // (re-)display view
Model *getModel( ) { return myModel; }
Controller *getcontroller( ) { return mycontroller; }
protected:
Model *myModel ;
Controller *myController; // set by initialize
};
class Barchartview : public View {
public:
BarChartView (Model *m) : View(m) { }
virtual void draw( ) ;
};

Implementação
void BarChartView::draw ( ) {
Iterator<String> ip = myModel->makePartyIterator();
Iterator<long> iv = myModel->makevoteIterator();
List<long> dl; //for scaling values to fill screen
long max = 1; // maximum for adjustment

// calculate maximum vote count
while (iv.next( )) {
if (iv.curr( ) > max ) max = iv.curr( ); }
iv.reset ( ) ;

// now calculate screen coordinates for bars
while (iv.next( )) {
dl.append((MAXBARS1ZE * iv.curr( ))/max); }

// reuse iterator object for new collection:
iv = dl; // assignment rebinds iterator to new list
iv.reset ( ) ;
while (ip.next( ) && iv.next( )) {
// draw text: cout << ip.curr 0 << " : " ;
// draw bar: ... drawbox(BARWIDTH, iv.curr0) ;...
}

Implementação
4. Projete e implemente os Controllers


Implementação
5. Projete e implemente o relacionamento
View-Controller
– Tipicamente, cada View tem o seu Controller
– Para criar uma hierarquia de classes, usa-se
o Padrão Factory.
• Define-se um makecontroller() nas classes View,
para que as subclasses View possam redefinir
seus Controllers redefinindo o método Factory


Implementação


Implementação
6. Implementar o set-up do MVC


Implementação
7. Criação (gerência) dinâmica de Views
8. Controllers plugáveis
• Diferentes controllers para um View (expert
versus iniciante ou diferentes dispositivos de
entrada)
9. Infra-estrutura para View e Controllers
hierárquicos


Variante
• Document-View
– Relaxamento da separação entre View e
Controller
– Ex.: X-Windows System


Benefícios
• Múltiplos Views do mesmo Model
• Views sincronizados
• Views e Controllers plugáveis
• “Permutabilidade” do “look-and-feel”


Desvantagens
• Complexidade maior
• Potencial para um número excessivo de updates
• Conexão íntima entre View e Controller
• Acoplamento de View e Controllers ao Model
• Ineficiência no acesso de dados no View
• Mudança inevitável do View e Controller quando
se porta a aplicação


MVC padrões arquiteturais

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (18)

Semelhante a MVC padrões arquiteturais

Semelhante a MVC padrões arquiteturais (20)

Mais de Eduardo Nicola F. Zagari

Mais de Eduardo Nicola F. Zagari (20)

MVC padrões arquiteturais