O documento discute os problemas da arquitetura BOLOVO, que separa projetos em Entidades, BLL e DAL. Apresenta que essa arquitetura foi criada para resolver problemas do Java antigo, mas não faz mais sentido para .NET hoje em dia, levando a códigos procedurais, classes anêmicas e baixa testabilidade, indo contra princípios como SOLID e DDD. Recomenda que desenvolvedores .NET evoluam e não usem mais BOLOVO, aprendendo DDD e TDD.
1. Bolovo: Não use por aí
7Masters OOD
Palestra de 7 minutos
29/10/2014
2. That’s me
• Priscila Mayumi Sato
• Twitter: @mayogax
• Fullstack Software Developer
• Microsoft MTAC
• PHPSP + Woman
• 7 anos de convivencia com .net <3
6. 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
7. 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”
9. 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/
10. 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
11. 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
12. 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
15. 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!!!
16. 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/
17. 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/
18. 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
19. 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
20. 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
22. 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!!
23. 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)