Bolovo - problema antigo de arquitetura de software - não use por aí
-
Upload
priscila-mayumi-sato -
Category
Technology
-
view
750 -
download
50
description
Transcript of Bolovo - problema antigo de arquitetura de software - não use por aí
Bolovo: Não use por aí7Masters OOD
Palestra de 7 minutos
29/10/2014
That’s me
• Priscila Mayumi Sato• Twitter: @mayogax• Fullstack Software Developer• Microsoft MTAC• PHPSP + Woman• 7 anos de convivencia com .net <3
Vamos começar um projetoComo projetos começam
Arquitetura?
Projeto
MVCEntidades(Models)
BLL(Busines Layer)
DLL(Data Layer)
Arquitetura?
Projeto
MVC
Entidades(Models)
BLL(Busines Layer)
DLL(Data Layer)
Simples e fácil
• O projeto MVC acessa as entidades• O projeto MVC acessa a BLL que contem a lógica• A BLL acessa as entidades• A BLL acessa a DAL para salvar na base de dados• A DAL acessa as entidades
• Arquitetura definida e projeto iniciado em 2 minutos• Simples e fácil
Quantos projetos começam assim?
• Entre no Github e procure por projetos .net (ou java)
• Quantas vezes você começou numa empresa que o código estava assim?
• Até hoje muitos tutoriais online pregam essa prática como “boa prática”
BOLOVOUm pouco de história
BOLOVO
• Em 2007 numa apresentação para o JustJava Paulo Silveira e introduziu o conceito de BOLOVO
• Traduzindo:• UsuarioBusinessObject (BO) – nossa BLL• UsuarioLayerObject (LO) – nosso projeto MVC• UsuarioValueObject (VO) – nosso projeto de entidades/models
• http://blog.caelum.com.br/justjava-2007-arquitetura-e-caelum/
BOLOVO
• Conceito nasceu na comunidade Java, mas como muitos projetos, conceitos e ideias são “importados” para o .net
• Até hoje existem tutoriais e projetos nascendo em arquitetura BOLOVO
BOLOVO - motivos
• “Esses design patterns faziam muito sentido quando no J2EE os entity beans não eram serializáveis, e sim acessados remotamente, além de que não existia injeção de dependência.”• Paulo Silveira – em 2007
• Em .net não havia esses motivos• A arquitetura BOLOVO foi importada para projetos .net para organizar códigos e prover uma estrutura de arquitetura cebola
BOLOVO – design das classes
• Entidade/Model:• Palestra
• BLL:• PalestraBLL
• DLL:• PalestraDLL
• MVC:• PalestraController
Várias classes irmãs com os mesmos nomes e sufixos indicando sua função
Uníca que realmente necessita ser escrita dessa forma
BOLOVOPorque não usar por aí
Problemas antigos
Não há necessidade para BOLOVO hoje• “Os programadores mais novos podem não ter sido
influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.”• http://blog.fragmental.com.br/2010/01/18/domain-
driven-bolovo-passando-conhecimento-e-etc/
PROCEDURAL!!!
Programação procedural
• Projeto em BOLOVO faz seu código ser procedural
• “ Veja, no momento que separamos dados de um lado, e comportamento de outro, voltamos a programar de maneira procedural. Nesse tipo de arquitetura, é comum vermos imensas classes com as regras de negócios repetidas e espalhadas. A consequência disso? Um código dificílimo de ser mantido e evoluído.”• http://blog.caelum.com.br/o-que-e-modelo-anemico-e-
por-que-fugir-dele/
Um projeto inteiro de gets e setters
• Projeto Entidades/Models inteiro de classes só com as propriedades
• Classes anémicas != orientação a objetos
• Classes que nem são testadas (só propriedades)
• Sobre criar classes só com gets e setters: http://blog.caelum.com.br/nao-aprender-oo-getters-e-setters/
Baixa testabilidade
• Projeto entidades/models não é testado
• Para testar BLL é preciso vários mocks de DAL (não necessáriamente uma coisa ruim, mas para você ver como há forte dependencia)
• Métodos na BLL gigantes e dificeis de serem testados (afinal é preciso um mesmo métodos ter testes de lógica e de dados, tudo junto e misturado)
• Uma odisséia para tentar usar TDD e você vai desistir logo no começo
Nada de SOLID
• Princípio da Responsabilidade Única• classes da BLL além de lógica controlam cada aspécto de um
model, inclusive a inserção na base de dados (as classes como PalestraBLL)
• Princípio do Aberto-Fechado • Ao mudar uma classe possivelmente vai mudar todas as
classes irmãs, cada inserção de funcionalidades precisa alterar outras classes em seguida tornando custoso a adição de novas funcionalidades
Nada de SOLID
• Princípio de Substituição de Liskov • Não há em projetos BOLOVO subtipos• Se houver herança um subtipo de BLL, por exemplo, não pode
ser substituidas por sua classe base
• Princípio da Segregação de Interfaces• Interfaces para BLL nunca conseguem ter somente o que a
classe precisa• Se possuem você provavelmente está colocando lógica nenhuma
• Princípio da Inversão de Dependência• Classes da BLL dependem de implementações concretas de DAL
e de Entidades/Models
Resumo da operaentãaaoooo
Resumo da opera
• BOLOVO cai bem... Se você programa em java em 2004
• Não é boa prática
• Dica: o projeto já nasce legado
• Não há necessidade de programadores .net continuarem nessa estrutura hoje, em 2014!!
O que eu faço então?
• Sugestão: aprenda DDD
• Aprenda TDD (se soubesse não estaria usando BOLOVO)
• Fuja da preguiça – se for programar em linguagem orientada a objetos não há pra que ser procedural
• Evolua e não pare no tempo (lembre: BOLOVO já era ruim em 2007)
Dúvidas?Criticas, sugestões, idéias, convites para jogar Magic?
Obrigada :D@MayogaX