Padrões de Arquitetura para desenvolvimento web e mobile

De Aulas
Revisão de 13h47min de 10 de setembro de 2021 por Admin (discussão | contribs) (→‎Desvantagens)

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.

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 apresnetar 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 controler 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

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:

Padrões de Criação

  • É 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 de criação
  • Abstract Factory
  • Object pool
  • Builder
  • Factory Method
  • Prototype
  • Singleton

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.
Padrões estruturais
  • Private class data
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade (ou Facade)
  • Business Delegate
  • Flyweight
  • Proxy


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.
Padrões comportamentais
  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

REFERÊNCIA

https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software#Padr%C3%B5es_GoF_('Gang_of_Four')

Disponível em “https://saulo.arisa.com.br/wiki/index.php?title=Padrões_de_Arquitetura_para_desenvolvimento_web_e_mobile&oldid=7674”