Your SlideShare is downloading. ×
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MVC já era! O negócio é DCI!

12,045

Published on

Palestra sobre o padrão de arquitetura DCI. Proferida na PHP Conference Brasil

Palestra sobre o padrão de arquitetura DCI. Proferida na PHP Conference Brasil

2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
12,045
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
117
Comments
2
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MVC já era! O negócio é DCI! Flávio Gomes da Silva Lisboa www.fgsl.eti @fgsl
  • 2. Quem sou eu Flávio Gomes da Silva Lisboa Bacharel em Ciência da ComputaçãoEspecialista em Aplicações Corporativas usando Orientação a Objetos e Tecnologia Java Instrutor e Consultor www.fgsl.eti.br flavio.lisboa@fgsl.eti.br Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
  • 3. Arquitetura
  • 4. Arquitetura
  • 5. Arquitetura(colocando medo nos corações)
  • 6. Arquitetura(colocando medo nos corações)
  • 7. Arquitetura(colocando medo nos corações)
  • 8. Arquitetura de Software Arquitetura é a essência da estrutura: é a forma  A estrutura ofusca a forma Arquitetura Enxuta: entrega sob demanda de funcionalidades, o que realmente gera valor. Arquitetura Ágil: a que suporta mudança, interação com o usuário final, descoberta e fácil compreensão (de funcionalidades)
  • 9. Lean Architecture“Arquitetura Enxuta”
  • 10. Lean Architecture “Arquitetura Enxuta” O “Pensamento Enxuto” (Lean Thinking), surgiu no final dos anos 80 do século XX, em um projeto do MIT sobre a indústria automobilística mundial. A pesquisa mostrou que a Toyota havia desenvolvido um novo paradigma de gestão nas principais dimensões dos negócios. Em 2009, a Toyota tornou-se a maior em volume de vendas, mostrando as vantagens e benefícios do sistema que desenvolveu.
  • 11. Lean Architecture “Arquitetura Enxuta” O “Pensamento Enxuto” é uma estratégia de negócios para aumentar a satisfação dos clientes através da melhor utilização dos recursos. O foco da implementaçao deve estar nas reais necessidades dos negócios.
  • 12. Qual o valor da arquitetura? A arquitetura suporta “o que acontece lá”. Código habitável – pelas pessoas que desenvolvem e pelas pessoas que o usam. A arquitetura é o que faz o código parecer familiar. Uma boa arquitetura reduz lixo e inconsistência -  Menos retrabalho  Consistência do sistema
  • 13. Arquitetura e Orientação a Objetos Orientação a Objetos (OO) é um paradigma – um modo de falar sobre a forma. Fundamentos de OO: capturar o modelo mental do usuário final no código. OO captura  As entidades (objetos) que os usuários conhecem  As classes que servem como conjuntos de tais objetos.
  • 14. MVC O que é isso?Algum mnemômico para Twitter?
  • 15. Model View Controller View Controller Model
  • 16. Model View Controller Controller View Model
  • 17. Projeto MVC
  • 18. Não ficou claro... Então vamos recorrer às analogias.
  • 19. Modelo
  • 20. Visão
  • 21. Controlador
  • 22. Capitão Marvel
  • 23. Capitão Marvel
  • 24. Remember, remember... Um mesmo nome identifica duas entidades distintas. O nome por si só, não tem nenhum significado. O nome é apenas um dado. Mas o dado, dentro de um contexto, traz informação para o receptor.
  • 25. MVC é a encarnação da visão OO O modelo mental do usuário é introduzido no código. O objetivo das visões é a manipulação direta – a interação com o usuário. O objetivo do controlador é coordenar múltiplas visões. Os dados do modelo podem ser apresentados de várias formas.
  • 26. Como nasceu o MVCO cientista norueguêsTrygve Reenskaug estavadesencantado com aarquitetura das linguagensSimula e Smalltalk.Em 1978, ele apresentouum padrão de projetochamado Model-View-Controller-User.
  • 27. MVCU?Mas onde foi parar o U?
  • 28. Os objetivos do MVCU Deixar que os usuários interagissem diretamente com o código que foi projetado como uma reflexão de seus próprios modelos mentais. É pra isso que serve a visão. Permitir que o usuário coordene várias visões simultâneas do mesmo modelo. É pra isso que serve o controlador. Isso é baseado na hipótese de que basta modelar a noção que o usuário final tem sobre o sistema de objetos.
  • 29. Mas arquitetura é mais do que isso A forma do domínio de negócio  O que o sistema é.  Modelo de Domínio (como no MVC).  Com o que o programador se preocupa. A forma das interações do sistema  O que o sistema faz.  Modelos de papéis: OORAM (Object Oriented Role Analysis and Modeling).  Com o que o usuário se preocupa.
  • 30. Análise e Modelagem de Papéis Orientada a Objetos Precursora da UML Caso de Uso Papel Responsabilidade
  • 31. De volta a OO: Outras formas na cabeça do usuário final Usuários pensam mais sobre os papéis manipulados por objetos do que nos objetos.  O que o sistema faz, novamente!  Dinheiro transferido de uma conta bancária: os papéis são a conta de origem e a conta de destino.  Os objetos poupança, conta de investimento podem todos fazer uso desses papéis. As associações de papéis para objetos, para um dado caso de uso, também é parte do modelo do usuário final.
  • 32. Ainda mais formas! E o algoritmo? O algoritmo também tem forma na cabeça do usuário.  Inicia a transação.  Debita a conta de origem.  Credita a conta de destino.  Finaliza a transação.
  • 33. De volta a OO: Outras formas na cabeça do usuário final O usuário está mais preocupado com as responsabilidades que são carregadas no sistema. A orientação a objetos tem servido aos programadores (o processo de descoberta, a arquitetura) mas não aos usuários e clientes – e muito menos à qualidade do software.
  • 34. Operações de Sistema: Separação de Interesses Computadores podem:  Armazenar e recuperar dados +  Transformar dados +  Comunicarem-se!!! A comunicação torna-se cidadã de primeira classe na computação. Programação orientada a classes: noodles DCI: Separação de interesses:  Cada tarefa codificada separadamente)
  • 35. Operações de Sistema: Separação de Interesses Execução de tarefas em um sistema Mensagem Operação Contexto
  • 36. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  • 37. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  • 38. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  • 39. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  • 40. Operações de Sistema: Executadas por Contextos Um Contexto (uma instância de uma classe de contexto).  Recebe uma mensagem.  É responsável por uma operação de sistema.  Dispara um método no primeiro papel.  A execução continua como especificado nos métodos do papel.
  • 41. Essas formas trazem uma nova arquitetura Papéis repletos de métodos (responsabilidades) Casos de UsoClasses de Domínio papéis sem Métodos Identificadores e c c
  • 42. Essas formas trazem uma nova arquiteturaA proposta de Trygve para uma nova arquiteturaé suportar a visão do usuário dos casos de usoe localizar algoritmos em um papelencapsulado.
  • 43. Essas formas trazem uma nova arquiteturaUma das formas maioreis dessa arquitetura,chamada forma (ou arquitetura),comportamental) básica, definida apenas emtermos de protocolos de papéis. Esses são ospapéis sem métodos. Compromissos. Contratos. Responsabilidades.
  • 44. Essas formas trazem uma nova arquiteturaO que Trygve adiciona são os papéis commétodos. Esses papéis podem invocar métodospróprios ou de outro papel.
  • 45. Papéis com MétodosEsses papéis são implementados como classes.Cada papel com métodos é injetado dentro deuma classe cujos objetos manipulam aquelepapel em algum momento de seu tempo de vida.A injeção é um tipo de operação de “colagem”,onde a lógica dos papéis com métodos éadicionada à lógica das classes.Cada classe se comportará de acordo com osmétodos dos papéis que foram “copiados” paradentro dele.
  • 46. Casos de UsoCada cenário de caso de uso é implementadocomo uma interação de algoritmos entrepapéis.Isso é um tipo de decomposição funcional, poismuitos usuários decompõem tarefas complexasem subtarefas.Em tempo de execução, associamos um papelsem métodos com um objeto que pode suportaros contratos, compromissos, daquele papel edeixamos o cenário ocorrer.
  • 47. Composição de ClassesPrecisamos compor algoritmos genéricos (penseem trechos de código), de papéis com métodoscom as classes cujos objetos manipulam essespapéis.Estamos falando de colar pedaços de código, enão classes inteiras.Entramos em um problema que não é resolvidopela mecanismo fundamental de reuso daorientação a objetos, a herança.
  • 48. Composição de ClassesUm objeto pode ter papéis variáveis de acordocom o contexto em que está operando.Um objeto pode adquirir responsabilidades emtempo de execução.Como atribuir poderes para um objeto que nãoforam definidos previamente?Como estabelecer a dependência entre objetosem tempo de execução?
  • 49. Palavras-chave Herança, Reuso, Lean ArchictetureDependência, Composição, Contexto
  • 50. Palavras-chave Acoplamento XDesacoplamento
  • 51. É hora de conhecer DCI O que é isso? Um mnemônico para mensagens instantâneas? “DCI pra gente tomar um café!”
  • 52. Data Context Interaction Interaction Context Data
  • 53. Data Context Interaction Context Interaction Data
  • 54. Data Context InteractionQuando estudamos um negócio, também devemos ter esse tipode preocupação. Separamos a Visão da Estrutura da Visão dosProcessos, cientes da maior complexidade e volatilidade dasegunda. Costumo dizer em meus treinamentos que a Visão dosProcessos ocupará, no mínimo, 70% do tempo de um analistade negócios. Acontece que a aplicação tradicional ouindisciplinada de conceitos OO, em determinado momento,mistura tudo. Através do padrão DCI essa separação é semprerespeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contextoé uma representação fiel de… um Caso de Uso!Paulo Vasconcelos, Finito Consultoria
  • 55. Dados
  • 56. Contexto
  • 57. Interação
  • 58. Como nasceu o DCI? Podemos considerar a publicação do artigo “The DCI Architecture: A New Vision of Object- Oriented Programming”, de James OCoplien e … Trygve Reenskaug, em 2009 The Brave and The Bold
  • 59. Solução para os problemas de composição Traits Injeção de dependências
  • 60. Traits Traits: Composing Classes from Behavioral Building Blocks Dissertação de Nathanael Scharli. Apresentada na Philosophisch- naturwissenschaftlichen Fakultat der Universitat Bern em 2005. Um simples modelo composicional que estende a herança simples.
  • 61. PHP 5.4trait [nome] {[bloco de código]}class [nome] extends [nome] { use [nome];}
  • 62. Injeção de dependênciasnamespace TomarreHelper;class Url{public function __construct(Request $request){ c$this->request = $request;}public function setRouter(Router $router){$this->router = $router;}}
  • 63. Injeção de dependênciasuse ZendDiDefinition,ZendDiReference;$mongo = new Definition(Mongo);$mongoDB = new Definition(MongoDB);$mongoDB->setParam(conn, new Reference(mongo))->setParam(name, test);$coll = new Definition(MongoCollection);$coll->setParam(db, new Reference(mongodb))->setParam(name, resource);$di->setDefinitions(array(mongo=> $mongo,mongodb => $mongoDB,resource => $coll,));$resource = $di->get(resource); 2
  • 64. Ou seja... Muita gente fala de MVC, mas poucos o implementam direito. Exemplo disso é a proliferação de modelos magros e controladores gordos. DCI não substitui MVC, apenas o complementa.
  • 65. Obrigado! Flávio Gomes da Silva Lisboa www.fgsl.eti.br flavio.lisboa@fgsl.eti.brLivre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl

×