Baixado 25 vezes
Carregado porPriscila Mayumi
Bolovo - problema antigo de arquitetura de software - não use por aí
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.
Mais conteúdo relacionado
Semelhante a Bolovo - problema antigo de arquitetura de software - não use por aí
Bolovo - problema antigo de arquitetura de software - não use por aí
- 1. Bolovo: Não usepor 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 umprojeto 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çamassim? • 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 poucode história
- 9. BOLOVO • Em2007 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 • Conceitonasceu 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 – designdas 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ãousar por aí
- 14.
- 15. Não há necessidadepara 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 inteirode 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 eufaç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.