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