Padrões de Arquitetura para desenvolvimento web e mobile

De Aulas
Revisão de 17h49min de 8 de setembro de 2021 por Admin (discussão | contribs)

Afluentes: Sistemas Distribuídos e Mobile

MVC - Model-View-Controller

O MVC (Model-View-Controller) é um padrão de projeto de software da 1970 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.

MVP - Model-View-Presenter

Padrão MVC
  • Separa a camada de apresentação das camadas de dados e regras de negócio
  • Dividido em três partes distintas
    • Model
    • View
    • Presenter

View

  • Exibe os dados
  • Não contém regras de negócio
  • Usado para disparar eventos que notificam mudanças de estado dos dados
  • A View implementa uma interface que expõe campos e eventos que o Presenter necessita

Model

  • São os objetos a serem manipulados
  • Implementa uma interface que expõe os campos que o Presenter atualiza quando sofrem atualização na View

Presenter

  • Mediação e ligação entre View e Model
  • Encarregado de atualizar a View quando o Model é alterado
  • Sincroniza o 'Model em relação ao View

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 sepraaçã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

De acordo com o livro: "Padrões de Projeto: soluções reutilizáveis de software orientado a objetos", os padrões "GoF" são divididos em 24 tipos. Em função dessa grande quantidade de padrões, foi necessário classificá-los de acordo com as suas finalidades.

São 3 as classificações/famílias:

  • É um padrão de criação
  • Serve para abstrair ou adiar o processo de criação dos objetos
  • Objetivam deixar o sistema independentem de como os objetos são criados, compostos e representados
  • Um padrão de criação de classe usa herança para variar a classe
  • Um padrão de criação de objeto delega a instanciação para outro objeto
  • Desenvolvimento baseado na ccomposição de objetos possibilita que eles não sejam compostos sem necessidade de expor seu interior
  • Os objetos encapsulam conhecimento sobre quais classes concretas são usadas pelo sistema
  • Os objetos ocultam o modo como essas classes são criadas e montadas
  • Para o sistema, os objetos são definidos por classes abstratas, dando flexibilidade no que é criado, quem cria, como e quando

Padrões estruturais

  • Se preocupam com a forma como classes e 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.


Tplnote Bulbgraph.png

A flexibilidade obtida pela composição de objetos provém da capacidade de mudar a composição em tempo de execução o que não é possível com a composição estática (herança de classes).

Padrões comportamentais

  • Se concentram nos 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.

Classificações / Famílias

Padrões de criação
  • Abstract Factory
  • Object pool
  • Builder
  • Factory Method
  • Prototype
  • Singleton
Padrões estruturais
  • Private class data
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade (ou Facade)
  • Business Delegate
  • Flyweight
  • Proxy
Padrões comportamentais
  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor
Disponível em “https://saulo.arisa.com.br/wiki/index.php?title=Padrões_de_Arquitetura_para_desenvolvimento_web_e_mobile&oldid=7656”