http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
Senhores, acredito que o conceito de VO, TO e DTO tenha ficado claro e a literatura (GOF e JEE Patterns) não deixa dúvida. Mas o conceito do POJO não está claro ainda; aí penso se alguém seria capaz de explicar estes conceitos pensando na arquitetura completa de um projeto? Tentarei começar:
Pensando em JSF:
1 - JSP submete a página, a requisição é interceptada por um CONTROLADOR(Servlet JSF) e alimenta um BEAN
2 - Caso existam, os dados são validados por VALIDATORS JSF
3 - Após a validação são chamados objetos de negócio (POJOs) que fazem o processamento dos dados(sacar, transferir, depositar) e chamam um FACADE para chamar as operações de banco;
4 - É criado um DAO que mascara as opções de banco (incluir, alterar, excluir e consultar)
5 - O dado é persistido.
Lembrando: É “RECOMENDÁVEL” que o POJO não extenda ou herde de nenhuma classe, mas se o fizer que exteda ou implemente classes e interfaces de negócio, não de infra-estrutura (como frameworks).
Será que falei alguma coisa errada?
Um abraço,
Novais.
Bem, resolvi ressuscitar esse tópico pq estava pesquisando sobre o assunto e esbarrei com ele.
Pela parábola do empréstimo de 10,00 do Philipp, tirei alguma conclusão, mas preciso de certeza. Fui discutir essa pendenga por aqui e, para variar, rolou uma baita divergência de opnião. É muito difícil estudar sobre esses assuntos, principalmente na Internet, pois parece não haver um consenso sobre o assunto.
Pelo que entendi:
Entity != VO (ou TO). E NUNCA será igual.
Basicamente porque Entity, normalmente, possui um ID que a torna única no sistema. Única em termos de dados, não confundir com o Pattern Singleton. E isso difere do conceito de VO: fowler
Foi a mesma coisa que entendi no artigo da MJ do Sérgio Lopes.
Essa é a sutileza?
Abraços.