Padrões de Arquitetura para desenvolvimento web e mobile

De Aulas
Revisão de 19h15min de 14 de setembro de 2021 por Admin (discussão | contribs) (→‎Model)

Afluentes: Sistemas Distribuídos e Mobile

MVC - Model-View-Controller

O MVC (Model-View-Controller) é um padrão de projeto de software lá pela década de 70 que tem como enfoque o reuso de código e a separação de conceitos em três camadas interconectadas, onde a apresentação dos dados e interação dos usuários (front-end) são separados dos métodos que interagem com o banco de dados (back-end).

Link para o material sobre Padrão MVC.

Exemplos

MVP - Model-View-Presenter

Padrão MVC
  • Separa a camada de apresentação das camadas de dados e regras de negócio
  • Minimiza-se o processamento da Interface do Usuário
  • Dividido em três partes distintas
    • Model
    • View
    • Presenter

View

  • Contém os controles da Interface do Usuário (UI)
  • Não trata das regras de negócios
  • Não tem nenhum comportamento sobre como os controles vão reagir aos eventos
  • As ações do usuário são gerenciadas pelo Presenter

Model

  • Contém os objetos com a lógica do negócio
  • Não tem conhecimento sobre a View
  • Facilita o reuso da lógica de negócio para diferentes contextos
  • Deve apresentar interfaces de forma abstrata, e não concreta

Presenter

  • Processa os eventos notificados pela View
  • Normalmente é feito pelo envio de mensagens ao Model
  • Conforme o Presenter atualiza o Model, a View é atualizada

MVP vs MVC

  • MVP é uma variante do MVC
  • no MVC, a View interage com o Model, o MVP não

Porque usar MVP?

  • Evita a baixa coesão de uma Autonomous View
  • Facilita nos testes automáticos
  • Diminui a complexidade comportamental porque ela é toda removida da View, deixando-a mais simples
  • Contudo, o presenter fica com a complexidade e deve ser fortemente acoplado à View.

Vantagens

  • Facilita a utilização de um framework de testes, uma vez que a lógica não está na Interface do Usuário
  • Cada código fica em seu devido lugar
  • Aumenta o reuso do modelo de domínio
  • Pode-se separar uma equipe conforme suas competências (Designers gráficos, programadores, especialísta de banco de dados, etc.)

Desvantagens

  • Mais código para implementar
  • Curva de aprendizado acentuada


Tplnote Bulbgraph.png

Será que vale a pena ter um objeto separado para controlar, já que ainda vai existir a complexidade?

Exemplos

MVVM - Model-View-ViewModel

Padrão MVVM
  • Padrão criado em 2005, por John Gossman, um dos arquitetos do WPF e Silverlight na Microsoft
  • Conceitualmente identico ao MVP
  • MVP é indepente de plataforma, mas o MVVM é específico para a arquitetura WPF e Silverlight
  • Objetiva estabelecer uma clara separação de responsabilidades em aplicações WPF e Silverlight
  • Mantém uma espécie de façade (ou fachada) entre o modelo de objetos e a View (interface do usuário)
  • Existe uma clara separação das camadas
  • A Model não conhece a View e vice-versa
  • A View conhece a ViewModel e se comunica via mecanismo binding
  • Mecanísmos binding são eventos roteados e comandos roteados
Padrao mvvm 2.png

View

  • Define a aparência, ou seja, interface do usuário
  • Referencia a ViewModel por meio da propriedade DataContext
  • Os controles são preenchidos com propriedades ou comandos, expostos na ViewModel

ViewModel

  • Não é uma classe visual
  • Disponibiliza para a View uma lógica de apresentação
  • Não tem conhecimeto sobre a View, seu tipo ou como ela é implementada
  • Implementa propriedades e comandos para que a View possa preencher os seus controles
  • Notifica a View no caso de mudança de estado

Model

  • Encapsula a lógica de negócios e dos dados
  • É o modelo de domínio de uma aplicação, ou seja, as classes de negócios
  • Contém os papéis e validação dos dados de acordo com o negócio

Exemplos e Links

GoF - Gang of Four

  • O livro "Design Patterns" (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm (Gang of Four) descreve 23 padrões de projeto
  • São soluções genéricas para os problemas mais comuns do desenvolvimento de software orientado a objetos
  • O livro é um clássico na literatura orientada a objetos
  • São documentações de soluções encontradas com experiências de sucesso na indústria de software

Classificações / Famílias

São três as classes de família: Padrões de Criação, estruturais e comportamentais.

Padrões de Criação

  • É um padrão de criação
  • Serve para abstrair ou adiar o processo de criação dos objetos
  • Tem o objetivo de dar independencia ao sistema da forma como os objetos são criados, compostos e representados
  • Tem um padrão de criação de classe usando herança para variar a classe
  • Tem um padrão de criação de objetos que delega a instanciação para outro objeto
  • O desenvolvimento é baseado na composição de objetos
  • Possibilita que os objetos sejam compostos sem necessidade de expor seu interior (encapsulamento)
  • O sistema enxerga os objetos como sendo definidos por classes abstratas. Isso dá maior flexibilidade no que é criado, quem cria, como e quando

Padrões estruturais

  • Responsávels pela forma como as classes e os objetos são compostos para formar estruturas maiores
  • Os padrões estruturais de classes utilizam a herança para compor interfaces ou implementações
  • Os padrões estruturais de objeto descrevem maneiras de compor objetos para obter novas funcionalidades.

Padrões comportamentais

  • São responsávels pelo comportamento, ou seja, algoritmos e atribuições de responsabilidades entre os objetos
  • Não descrevem apenas padrões de objetos ou de classes, mas também os padrões de comunicação entre os objetos
  • Os padrões comportamentais de classes utilizam a herança para distribuir o comportamento entre classes
  • Os padrões de comportamento de objeto utilizam a composição de objetos em contrapartida a herança
  • Possibilidade de descrever como grupos de objetos que cooperam para a execução de uma tarefa que não poderia ser executada por um objeto sozinho.
Padrões GoF

Links