A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Padrões Arquiteturais Layers, Façade, Repositório, Eventos, MVC Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)

Apresentações semelhantes


Apresentação em tema: "Padrões Arquiteturais Layers, Façade, Repositório, Eventos, MVC Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)"— Transcrição da apresentação:

1 Padrões Arquiteturais Layers, Façade, Repositório, Eventos, MVC Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)

2 O que vimos na última aula? Arquitetura de software O que é? O que é? Para que serve? Para que serve? Como documentar? Como documentar? O que é padrão arquitetural 2 Padrão Layers (Camadas)

3 O que veremos agora? Padrões arquiteturais 3 Padrão Layers (Camadas)

4 Problema Como projetar um sistema cuja característica principal é uma mistura de funcionalidades de alto nível e de baixo nível... Como projetar um sistema cuja característica principal é uma mistura de funcionalidades de alto nível e de baixo nível onde a parte de baixo nível está frequentemente perto do hardware onde a parte de baixo nível está frequentemente perto do hardware......e a parte de mais alto nível está frequentemente perto do usuário?...e a parte de mais alto nível está frequentemente perto do usuário? O fluxo de comunicação tipicamente consiste de pedidos fluindo do alto nível para o baixo nível O fluxo de comunicação tipicamente consiste de pedidos fluindo do alto nível para o baixo nível E as respostas seguem a direção contrária E as respostas seguem a direção contrária 4 Padrão Layers (Camadas)

5 Problema 5 Interface Relatório Armazenamento Negócio Contextos das classes CAOS!!!

6 Solução Decomposição do sistema: partições e camadas Decomposição do sistema: partições e camadas Uma camada é um subsistema que adiciona valor a subsistemas de menor nível de abstração Uma camada é um subsistema que adiciona valor a subsistemas de menor nível de abstração Uma partição é um subsistema "paralelo" a outros subsistemas Uma partição é um subsistema "paralelo" a outros subsistemas 6 Padrão Layers (Camadas) Camada n Camada 2 Camada 1 Partição n_1Partição n_2Partição n_3Partição n_4 Partição 2_1Partição 2_2Partição 2_3Partição 2_4 Partição 1_1Partição 1_2

7 Padrão Layers (Camadas) Solução 7 Apresentação Lógica de Negócio/Domínio Fonte de dados/Armazenamento Interface Gráfica Interface Texto VendasCompras Acesso a SGBDAcesso a XML

8 Conseqüências Vantagens Vantagens Reúso de camadas Reúso de camadas Devido ao bom encapsulamento provido pelo uso de interfaces Devido ao bom encapsulamento provido pelo uso de interfaces Suporte para a padronização Suporte para a padronização Certas camadas importantes podem ser padronizadas Certas camadas importantes podem ser padronizadas ex. API POSIX ex. API POSIX Permite usar implementações de vários fornecedores Permite usar implementações de vários fornecedores Dependências são mantidas locais Dependências são mantidas locais Alterações de implementações que não alterem as interfaces não saem da camada Alterações de implementações que não alterem as interfaces não saem da camada Intercambiabilidade Intercambiabilidade Implementações podem ser trocadas Implementações podem ser trocadas 8 Padrão Layers (Camadas)

9 Conseqüências Desvantagens Desvantagens Cascatas de mudanças de comportamento Cascatas de mudanças de comportamento Sob certas situações, alterações de comportamento numa camada podem fazer cascata Sob certas situações, alterações de comportamento numa camada podem fazer cascata ex. alteração de um enlace de 10 Mbps para 1Gbps pode causar gargalos nas camadas superiores ex. alteração de um enlace de 10 Mbps para 1Gbps pode causar gargalos nas camadas superiores Menor eficiência Menor eficiência Camadas adicionam overhead Camadas adicionam overhead Um "mar monolítico de objetos" pode ser mais eficiente Um "mar monolítico de objetos" pode ser mais eficiente Porém, mais acoplado Porém, mais acoplado 9 Padrão Layers (Camadas)

10 Como implementar?

11 Implementação 1. Defina o critério de abstração para agrupar tarefas em camadas Pode ser a distância conceitual do "chão Pode ser a distância conceitual do "chão ou outro critério dependente do domínio Pode ser baseado na complexidade conceitual Pode ser baseado na complexidade conceitual Uma forma comum de criar camadas Uma forma comum de criar camadas Nas camadas inferiores, usa a distância do hardware Nas camadas inferiores, usa a distância do hardware Nas camadas superiores, usa a complexidade conceitual Nas camadas superiores, usa a complexidade conceitual Exemplo de camadas: Exemplo de camadas: Elementos visíveis ao usuário Elementos visíveis ao usuário Módulos específicos da aplicação Módulos específicos da aplicação Nível de serviços comuns Nível de serviços comuns Nível de interface ao sistema operacional (ou outra plataforma como uma JVM) Nível de interface ao sistema operacional (ou outra plataforma como uma JVM) O sistema operacional em si que pode estar estuturado em camadas O sistema operacional em si que pode estar estuturado em camadas 11 Padrão Layers (Camadas)

12 2. Determine o número de níveis de abstração (baseado no critério anterior) Cada nível de abstração corresponde a uma camada Cada nível de abstração corresponde a uma camada Às vezes não é simples decidir se deve haver uma quebra de uma Às vezes não é simples decidir se deve haver uma quebra de uma Camadas demais podem afetar o desempenho Camadas demais podem afetar o desempenho Camadas de menos comprometem a estrutura Camadas de menos comprometem a estrutura 12 Padrão Layers (Camadas)

13 3. Dê um nome e atribua tarefas a cada camada Para a camada de cima, a tarefa é a tarefa global do sistema, do ponto de vista do usuário Para a camada de cima, a tarefa é a tarefa global do sistema, do ponto de vista do usuário Outras camadas existem para ajudar as camadas de cima Outras camadas existem para ajudar as camadas de cima Pode-se proceder de baixo para cima, mas isso requer bastante experiência Pode-se proceder de baixo para cima, mas isso requer bastante experiência Melhor proceder de cima para baixo Melhor proceder de cima para baixo 13 Padrão Layers (Camadas)

14 4. Especifique os serviços O princípio básico é de separar as camadas uma das outras O princípio básico é de separar as camadas uma das outras Nenhum módulo abrange duas camadas Nenhum módulo abrange duas camadas Tente manter mais riqueza (semântica) acima e menos abaixo Tente manter mais riqueza (semântica) acima e menos abaixo Isso ajuda a prover bons serviços de alto nível para o programador "em cima Isso ajuda a prover bons serviços de alto nível para o programador "em cima "pirâmide invertida de reuso" "pirâmide invertida de reuso" 14 Padrão Layers (Camadas)

15 5. Refine as camadas Itere nas 4 etapas anteriores Itere nas 4 etapas anteriores Dificilmente se acerta o critério de abstração de primeira, antes de ver que camadas estão surgindo Dificilmente se acerta o critério de abstração de primeira, antes de ver que camadas estão surgindo Quando as camadas surgem, pode-se verificar se o critério de abstração está ok Quando as camadas surgem, pode-se verificar se o critério de abstração está ok 15 Padrão Layers (Camadas)

16 6. Especifique uma interface para cada camada Black box (preferível) Black box (preferível) A camada J nada sabe sobre a camada J-1 e usa uma interface "plana" para acessá-la A camada J nada sabe sobre a camada J-1 e usa uma interface "plana" para acessá-la Pode usar o padrão Façade para organizar a interface Pode usar o padrão Façade para organizar a interface White box White box A camada J conhece detalhes da estrutura interna da camada J-1 e usa esse conhecimento ao acessar a camada A camada J conhece detalhes da estrutura interna da camada J-1 e usa esse conhecimento ao acessar a camada Por exemplo, conhece vários objetos ou componentes internos da camada Por exemplo, conhece vários objetos ou componentes internos da camada 16 Padrão Layers (Camadas)

17 7. Estruture as camadas individuais Quebre a camada em subsistemas (partições) menores se ela for complexa Quebre a camada em subsistemas (partições) menores se ela for complexa 17 Padrão Layers (Camadas)

18 8. Especifique a comunicação entre camadas Normalmente, usa-se o modelo push Normalmente, usa-se o modelo push A camada J passa a informação necessária para a camada J-1 ao chamá-la A camada J passa a informação necessária para a camada J-1 ao chamá-la O modelo pull pode ser usado mas cria mais acoplamento entre camadas O modelo pull pode ser usado mas cria mais acoplamento entre camadas Uma discussão será feita no padrão Observer Uma discussão será feita no padrão Observer 18 Padrão Layers (Camadas)

19 9. Desacoplar camadas adjacentes Evite situações em que a camada de baixo sabe algo sobre seus clientes (camada acima) Evite situações em que a camada de baixo sabe algo sobre seus clientes (camada acima) Acoplamento unidirecional é preferível (push) Acoplamento unidirecional é preferível (push) A grande técnica de desacoplamento é usar uma interface A grande técnica de desacoplamento é usar uma interface 19 Padrão Layers (Camadas)

20 10. Projete uma estratégia de tratamento de erros O esforço de programação e overhead podem ser grandes para tratar erros numa arquitetura em camadas O esforço de programação e overhead podem ser grandes para tratar erros numa arquitetura em camadas Um erro pode ser tratado na camada onde foi descoberto ou numa camada superior Um erro pode ser tratado na camada onde foi descoberto ou numa camada superior No segundo caso, deve haver mapeamento para tornar o erro semanticamente reconhecível pela camada de cima No segundo caso, deve haver mapeamento para tornar o erro semanticamente reconhecível pela camada de cima Exemplo: Não apresente ao usuário uma mensagem dizendo "Exceção IllegalArgumentException em DoItNow ()" Exemplo: Não apresente ao usuário uma mensagem dizendo "Exceção IllegalArgumentException em DoItNow ()" Tente tratar erros na camada mais baixa possível Tente tratar erros na camada mais baixa possível Isso simplifica todas as camadas superiores que não sabem nem devem saber do erro Isso simplifica todas as camadas superiores que não sabem nem devem saber do erro "O componente mais rápido, mais robusto e mais barato é aquele que não está aí" "O componente mais rápido, mais robusto e mais barato é aquele que não está aí" 20 Padrão Layers (Camadas)

21 Arquitetura n-camadas Inicialmente... Inicialmente... Arquitetura centralizada Arquitetura centralizada Dominantes até a década de 80 como arquitetura corporativa Dominantes até a década de 80 como arquitetura corporativa Problema básico: interface não amigável Problema básico: interface não amigável 21 Padrão Layers (Camadas)

22 2-camadas Arquitetura em 2 camadas Arquitetura em 2 camadas Melhor aproveitar os PCs da empresa Melhor aproveitar os PCs da empresa Interfaces gráficas amigáveis Interfaces gráficas amigáveis Integrar o desktop aos dados corporativos Integrar o desktop aos dados corporativos 22 Padrão Layers (Camadas)

23 Arquitetura em 2 camadas Arquitetura em 2 camadas 23 Padrão Layers (Camadas)

24 3-camadas Arquitetura em 3 camadas Arquitetura em 3 camadas Motivação Motivação Arquitetura em 2 camadas possui vários problemas: Arquitetura em 2 camadas possui vários problemas: Múltiplas conexões com o banco de dados Múltiplas conexões com o banco de dados Manutenção (mudanças forçam instalações nos clientes) Manutenção (mudanças forçam instalações nos clientes) 24 Padrão Layers (Camadas)

25 Arquitetura em 3 camadas Arquitetura em 3 camadas Observe que as camadas são lógicas... Observe que as camadas são lógicas Padrão Layers (Camadas)

26 Arquitetura em 3/4 camadas (web-based) Arquitetura em 3/4 camadas (web-based) Instalação inicial nos clientes é cara Instalação inicial nos clientes é cara Manutenção na camada de apresentação requer instalações Manutenção na camada de apresentação requer instalações Instalações do software fora do seu controle administrativo são complicadas Instalações do software fora do seu controle administrativo são complicadas Parceiros Parceiros Fornecedores Fornecedores Clientes distribuídos Clientes distribuídos Internet Internet 26 Padrão Layers (Camadas)

27 Arquitetura em 3/4 camadas (web-based) Arquitetura em 3/4 camadas (web-based) Utilizou-se então o browser como cliente universal Utilizou-se então o browser como cliente universal 27 Padrão Layers (Camadas)

28 Exemplos (arquitetura em n camadas) Arquitetura em n camadas Arquitetura em n camadas Como suportar clientes leves??? Como suportar clientes leves??? Como suportar componentização? Como suportar componentização? Como facilitar a vida do desenvolvedor para gerenciar (transações, pooling, persistência de dados...) Como facilitar a vida do desenvolvedor para gerenciar (transações, pooling, persistência de dados...) 28 Padrão Layers (Camadas)

29 Exemplos (arquitetura em n camadas) 29 Padrão Layers (Camadas) middleware

30 Padrão arquitetural E de projeto de baixo nível: Façade(Fachada)

31 31 Façade A arquitetura de um sistema dividido em camadas, possui dependências entre classes de camadas adjacentes Armazenamento Negócio Apresentação Pequenas mudanças locais em classes de uma camada... Resulta em mudanças em outras camadas!!!

32 32 Problema: Como garantir baixo acoplamento entre as camadas... sabendo que é inevitável o relacionamento entre classes de camadas diferentes??? Resposta: Padrão Façade Intenção Definir um ponto único de acesso a um subsistema para isolá-lo e garantir baixo acoplamento com classes externas. Definir um ponto único de acesso a um subsistema para isolá-lo e garantir baixo acoplamento com classes externas.Aplicabilidade Fornecer uma interface simples a um sistema complexo Fornecer uma interface simples a um sistema complexo Estruturar melhor as camadas do sistema Estruturar melhor as camadas do sistema Diminui dependências entre clientes e classes de implementação Diminui dependências entre clientes e classes de implementação

33 33 Façade Define-se uma fachada de acesso a cada camada Armazenamento Negócio Apresentação Fachada Alterações locais alteram a fachada! Classes cliente permanecem inalteradas!!!

34 34 Estrutura de classes a ntes da aplicação do padrão Matrícula Relatório GerenciadorImpressão InterfaceGráfica efetuarMatricula() gerarRelatorio() Camada de negócio Imprimir()

35 35 Após a aplicação do padrão Matrícula Relatório GerenciadorImpressão InterfaceGráfica efetuar gerar Camada de negócio imprimir FachadaSistema gerarRelatório() imprimirRelatorio() efetuarMatricula() VerificadorAdicional Agora... antes de efetuar a matrícula!!! Preciso verificar!!!! verificar boolean efetuarMatricula(){ return verificar()&&efetuar(); }

36 36 Conseqüências Isola os clientes dos componentes internos do sistema Isola os clientes dos componentes internos do sistema Promove baixo acoplamento entre o subsistema e os clientes Promove baixo acoplamento entre o subsistema e os clientes Não impede clientes de utilizarem componentes diretamente, caso seja necessário Não impede clientes de utilizarem componentes diretamente, caso seja necessário

37 37 Padrão Repositório (compartilhado) Problema Como fazer com que várias aplicações-cliente possam interoperar? Como fazer com que várias aplicações-cliente possam interoperar? Integridade, escalabilidade (novos clientes, novos dados) Integridade, escalabilidade (novos clientes, novos dados) Aplicações são independentes Aplicações são independentes Pontes entre aplicações são inviáveis Pontes entre aplicações são inviáveis

38 38 Padrão Repositório Solução Padrão Repositório Padrão Repositório Centrado em dados Centrado em dados Ponto central de acesso pelas várias aplicações Ponto central de acesso pelas várias aplicações Interoperabilidade alcançada através da mudança de estado do repositório (atualização dos dados) Interoperabilidade alcançada através da mudança de estado do repositório (atualização dos dados)

39 39 Padrão Repositório Solução Dados compartilhados Cliente 1 Cliente 2 Cliente 3 Cliente n Estado atual consistente Clientes operam sobre os dados

40 40 Padrão Repositório Exemplo: banco de dados tradicional Dados compartilhados Cliente 1 Cliente 2 Cliente 3 Cliente n Transações Gatilhos (triggers)

41 41 Consequências Novas aplicações-cliente podem ser adicionadas à arquitetura sem alteração nas demais Novas aplicações-cliente podem ser adicionadas à arquitetura sem alteração nas demais Desde que o modelo de repositório não seja alterado significativamente Desde que o modelo de repositório não seja alterado significativamente Tem-se sempre um estado consistente no repositório, independente da execução das aplicações Tem-se sempre um estado consistente no repositório, independente da execução das aplicações Desvantagens Desvantagens Ponto central de falha Ponto central de falha Gargalo Gargalo Difícil compreensão Difícil compreensão Necessita de mecanismo de sincronização Necessita de mecanismo de sincronização

42 Arquitetura baseada em eventos (padrão) 42

43 43 Arquitetura baseada em eventos Problema Como criar uma relação 1-para-muitos entre módulos da arquitetura mantendo o baixo acoplamento entre eles? Como criar uma relação 1-para-muitos entre módulos da arquitetura mantendo o baixo acoplamento entre eles? Cada módulo está interessado apenas na mudança de estado do outro Cada módulo está interessado apenas na mudança de estado do outro Módulo A, B, C e D precisam executar uma dada rotina quando o módulo X alcançar um determinado estado

44 44 Problema Uma possível solução seria a ligação entre os componentes... Muito acoplada, pouco escalável... Arquitetura baseada em eventos A imprimir X a.imprimir()

45 45 Arquitetura baseada em eventos Solução Arquitetura baseada em eventos Arquitetura baseada em eventos Produtores (anunciantes) e consumidores (interessados) de eventos Produtores (anunciantes) e consumidores (interessados) de eventos Consumidores se registram nos Produtores Consumidores se registram nos Produtores Produtores notificam consumidores registrados Produtores notificam consumidores registrados

46 46 Arquitetura baseada em eventos Solução Produtores e consumidores são independentes Produtores e consumidores são independentes Execução via procedimentos disparados quando ocorrem mudanças de estado Execução via procedimentos disparados quando ocorrem mudanças de estado Escalabilidade no número de interessados Escalabilidade no número de interessados AX Produtor Consumidor interessado(relatorioOK) relatorioOK Relatório OK imprimir()

47 47 Arquitetura baseada em eventos Exemplo Interface gráfica Interface gráfica menuDown onMouseOver onMouseClick onMousePressed onMouseReleased onSelected onKeyDown onKeyUp

48 48 Arquitetura baseada em eventos Conseqüências Módulos desacoplados Módulos desacoplados Novos componentes interessados podem ser facilmente adicionados à arquitetura Novos componentes interessados podem ser facilmente adicionados à arquitetura Escalabilidade Escalabilidade Desvantagem: Desvantagem: Caso haja novos eventos, interessados devem ser alterados!!! Caso haja novos eventos, interessados devem ser alterados!!!

49 49 Arquitetura baseada em eventos Testando seus conhecimentos Como garantir, no nível de projeto e implementação, a independência entre os interessados e os anunciantes dos eventos? Esta resposta será dada quando o padrão Observer for apresentado, mas alguém tem alguma sugestão? Esta resposta será dada quando o padrão Observer for apresentado, mas alguém tem alguma sugestão?

50 50 Padrão MVC Problema Interfaces com o usuário são sensíveis a mudanças: Interfaces com o usuário são sensíveis a mudanças: A aplicação pode ter que ser implementada em outra plataforma. A aplicação pode ter que ser implementada em outra plataforma. Diferentes requisitos de acordo com o usuário: Diferentes requisitos de acordo com o usuário: Um digitador pode preferir uma interface onde tudo pode ser feito através do teclado e visualizado como texto. Um digitador pode preferir uma interface onde tudo pode ser feito através do teclado e visualizado como texto. Um gerente pode preferir uma interface com botões, para utilizar o mouse Um gerente pode preferir uma interface com botões, para utilizar o mouse Se o código da interface gráfica é muito acoplado ao código da aplicação, o desenvolvimento pode se tornar muito caro e difícil. Se o código da interface gráfica é muito acoplado ao código da aplicação, o desenvolvimento pode se tornar muito caro e difícil.

51 51 Padrão MVC Solução Padrão MVC Padrão MVC Separar dados ou lógica de negócios (Model) da interface do usuário (View) e do fluxo da aplicação (Control) Separar dados ou lógica de negócios (Model) da interface do usuário (View) e do fluxo da aplicação (Control) Uma mesma lógica de negócios possa ser acessada e visualizada através de várias interfaces. Uma mesma lógica de negócios possa ser acessada e visualizada através de várias interfaces. O modelo (Model) não sabe quantas nem quais interfaces com o usuário estão exibindo seu estado. O modelo (Model) não sabe quantas nem quais interfaces com o usuário estão exibindo seu estado.

52 52 Padrão MVC Solução Com as diversas possibilidades de interfaces que conhecemos hoje, MVC é uma ferramenta indispensável Com as diversas possibilidades de interfaces que conhecemos hoje, MVC é uma ferramenta indispensável

53 53 Padrão MVC Implementação Passo 1 Passo 1 Isolar a lógica de negócio do sistema Isolar a lógica de negócio do sistema As classes de negócio não devem conhecer nada relacionado à(s) interface(s) de exibição do seu estado As classes de negócio não devem conhecer nada relacionado à(s) interface(s) de exibição do seu estado

54 54 Padrão MVC Implementação Passo 2 Passo 2 Se as classes de negócio não conhecem a interface gráfica... como fazer para que o modelo informe mudanças em seu estado para as diversas interfaces? Se as classes de negócio não conhecem a interface gráfica... como fazer para que o modelo informe mudanças em seu estado para as diversas interfaces?

55 55 Padrão MVC Implementação Passo 2 Passo 2 Arquitetura baseada em eventos!!! Arquitetura baseada em eventos!!! As telas interessadas em exibir os eventos do modelo, cadastram-se nos controladores As telas interessadas em exibir os eventos do modelo, cadastram-se nos controladores Além disso, controladores são responsáveis por repassar as requisições das visões para o modelo. Além disso, controladores são responsáveis por repassar as requisições das visões para o modelo. Implementar os controladores de acesso ao modelo Implementar os controladores de acesso ao modelo

56 56 Padrão MVC Implementação Passo 3 Passo 3 Implementar as visões que, através do controlador, acessarão o estado do modelo Implementar as visões que, através do controlador, acessarão o estado do modelo View Controller Model

57 57 Padrão MVC Responsabilidades Modelo (Model) Modelo (Model) Funcionalidade principal da aplicação Funcionalidade principal da aplicação Registrar controllers e views Registrar controllers e views Notificar controllers e views registrados de alterações Notificar controllers e views registrados de alterações Visão (View) Visão (View) Criar e inicializar o controlador associado Criar e inicializar o controlador associado Exibir informação ao usuário Exibir informação ao usuário Implementar o procedimento de atualização Implementar o procedimento de atualização Recuperar dados do modelo Recuperar dados do modelo

58 58 Padrão MVC Responsabilidades Controlador (Controller) Controlador (Controller) Receber a entrada de dados/requisições do usuário Receber a entrada de dados/requisições do usuário Transformar as requisições dos usuários em requisições ao modelo Transformar as requisições dos usuários em requisições ao modelo Implementar o procedimento de atualização (se necessário) Implementar o procedimento de atualização (se necessário)

59 59 Padrão MVC Conseqüências Vantagens Vantagens Suporte a múltiplas interfaces de usuário utilizando o mesmo modelo de negócio Suporte a múltiplas interfaces de usuário utilizando o mesmo modelo de negócio Novas interfaces podem ser adicionadas sem alteração do modelo Novas interfaces podem ser adicionadas sem alteração do modelo Alterações no estado do modelo são refletidas em todas as visões Alterações no estado do modelo são refletidas em todas as visões

60 60 Padrão MVC Conseqüências Desvantagens Desvantagens Com muitas visões e modelo atualizado com muita freqüência, o desempenho do sistema pode ser afetado. Com muitas visões e modelo atualizado com muita freqüência, o desempenho do sistema pode ser afetado. Se o padrão não for bem implementado, pode-se ter casos como o envio de atualizações para visões que estão minimizadas ou fora do campo de visão do usuário. Se o padrão não for bem implementado, pode-se ter casos como o envio de atualizações para visões que estão minimizadas ou fora do campo de visão do usuário. Ineficiência: uma visão pode ter que fazer inúmeras chamadas ao modelo, dependendo de sua interface. Ineficiência: uma visão pode ter que fazer inúmeras chamadas ao modelo, dependendo de sua interface.

61 61 Padrão MVC Quando usar? Necessidade de várias interfaces com o usuário Necessidade de várias interfaces com o usuário Web, Swing Web, Swing Necessidade de várias visões dos dados Necessidade de várias visões dos dados Planilhas, Tabelas, Gráficos Planilhas, Tabelas, Gráficos Mudanças nos dados devem ser refletidas na interface Mudanças nos dados devem ser refletidas na interface

62 62 Padrão MVC Em Java, vários frameworks disponíveis... Apache Struts Apache Struts Apache Cocoon Apache Cocoon Spring MVC Spring MVC WebWork WebWork JavaServer Faces JavaServer Faces Grails Grails

63 O que vimos? Padrão Layers (Camadas) Padrão Façade Padrão Repositório Arquitetura baseada em eventos MVC 63

64 O que veremos na próxima aula? Estudos de caso de arquiteturas 64 Padrão Layers (Camadas)

65 Dúvidas? ? 65 Padrão Layers (Camadas)


Carregar ppt "Padrões Arquiteturais Layers, Façade, Repositório, Eventos, MVC Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)"

Apresentações semelhantes


Anúncios Google