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

3. Vamos começar um projeto
Como projetos começam

4. Arquitetura?
Projeto
MVC
Entidades
(Models)
BLL
(Busines
Layer)
DLL
(Data Layer)

5. Arquitetura?
Projeto
MVC
Entidades
(Models)
BLL
(Busines
Layer)
DLL
(Data Layer)

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”

8. BOLOVO
Um pouco de história

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

13. BOLOVO
Porque não usar por aí

14. Problemas antigos

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

21. Resumo da opera
entãaaoooo

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)

24. Dúvidas?
Criticas, sugestões, idéias, convites para jogar Magic?

25. Obrigada :D
@MayogaX