[quote=Fabio Kung][quote=rodrigoy]“É uma boa idéia alocar o máximo de inteligência no entity?”
[/quote]
Eu uso bastante bom senso…
Minha resposta vazia seria: “desde que a inteligência seja suficientemente relacionada à entidade”[/quote]
foi uma boa observação essa sua
Em sistemas complexos que vão além de operações CRUD é primordial o uso de operações de negócio nos entities.
[quote=okara][quote=‘kenobi’]
Mesmo que a regra de negócio trate somente a entidade em questão, não acho elegante e nem faz bem para a manutenibilidade do sistema
[/quote]
Em sistemas complexos que vão além de operações CRUD é primordial o uso de operações de negócio nos entities.
[/quote]
Sinceramente não gosto desse approach de desenvolvimento, entretanto sou flexível à mudança, se eu perceber que está correto o paradigma, seu ponto de vista.
Alguém pra argumentar à favor ?
Mas não é isso que a OO diz para fazer?
Na minha visão, o entity não persisti. O seu estado é persistido. É ai que começa a confusão. É o entity quem sabe gerenciar o seu próprio estado, e não uma outra camada do sistema.
Aqui eu encaro o seguinte: A view informa a fachada solicitando o cancelamento da duplicata. A fachada por sua vez recebe o entity e chama o método cancela (do entity) para que o seu estado corresponda a uma duplicata cancelada. Depois é só salvar o estado do entity. Ou seja:
public void cancelaDuplicata(Duplicata duplicata) {
duplicata.cancela();
duplicata.save(); // ou entityManager.save(duplicata), por exemplo
}Ao meu ver, a manutenção vai ficar mais fácil. Por que não faz bem para a manutenabilidade do sistema?
Esse é mais um caso para o Shoes.
Não vou ser eu Felipe!
É claro que OO não resolve todos os problemas do mundo, mas separar os dados (seus Entities = structs) da lógica (suas Business classes = biblioteca de funções) é procedural demais.
A questão seria então debater se OO é melhor ou não que programação procedural para estes casos. Acredito que o tempo já tenha dado a resposta.
[quote=Thiago Senna]Aqui eu encaro o seguinte: A view informa a fachada solicitando o cancelamento da duplicata. A fachada por sua vez recebe o entity e chama o método cancela (do entity) para que o seu estado corresponda a uma duplicata cancelada. Depois é só salvar o estado do entity. Ou seja:
[code]
public void cancelaDuplicata(Duplicata duplicata) {
duplicata.cancela();
duplicata.save(); // ou entityManager.save(duplicata), por exemplo
}
[/code][/quote]
Também acho que é bem por aí. Essa fachada serve bem para demarcar uma transação/caso de uso e o domain model é responsável pela lógica de negócios.
A criação de classes a mais de fachada (essa com o método cancelaDuplicata, por exemplo) ainda é um pouco discutível, tendo em vista que (dependendo do contexto) essa “fachada” poderia ser diretamente a sua Servlet, Action, Componente, SessionBean, WebService, <coloque aqui seu tratador de requisições favorito>.
Eu disse dependendo do contexto pq alguns poucos cenários exigem essa camada a mais de fachadas (vale a pena um exemplo?). Nos tempos de hoje o reaproveitamento é alcançável expondo os serviços (webservices, rest, ejbs, …) e quanto mais simples a coisa for, melhor.
Diria o contrário. Que tal uma relida nos artigos do shoes acima?
Realmente reli e baixei o livro de DDD do InfoQ.
Preciso começar a mudar a forma de pensar, que foram sendo injetadas na mente durante anos de Design Patterns publicados como boas práticas entre outros.
É um novo paradigma e conceito, precisa pensar analisar e amadurecer a arquitetura para tirar proveito de tal.
Chun, como disse, se provar que estou errado como foi o caso, eu mudo minha forma de pensar… afinal, insistir no erro é complicado.
Gosto de discutir idéias até pra adotar outra linha de pensamento e expandir as possibilidades 
Quem bom seria, se todos fossem assim!
Bom, vou passar um pouco da minha experiência aqui. Alocar o máximo de inteligência nos entities aproxima seu modelo de objetos ao modelo de negócios e isso é muito bom para a coesão e manutenção do sistema. Entities que refletem o negócio até exigem menor esforço de documentação do sistema.
Mas como todas as decisões arquiteturais, isso deixa efeitos colaterais no seu colo como já discutimos aqui. Para uma arquitetura Spring e EJB3 que são as abordagens mais utilizadas para Java, não é natural que um entity manipule, ou crie outros entities que não fazem parte de uma associação.
As coisas estão melhorando bastante, mas ainda tem muito a evoluir!
Um dos problemas que vejo é que as arquiteturas ou alguns workarounds que são definidos como “patterns” algumas vezes forçam os desenvolvedores a cometerem erros.
É verdade Rodrigo, parece que os grandes players do mercado não “incentivam” o uso do conceito de domain model.
Meio atrasado, mas vou tentar fazer uma humilde contribuicao.
Acho que muitos nao recomendam o modelo de dominio pois e dificil atingir uma boa velocidade de desenvolvimento! Estou tentando a um tempo ta dificil! E tbem cada caso e um caso imagina fazer um soft pro seu Jose da padaria usando DM, acho que realmente tem que dozar.
Voltando a discussao:
Sempre que penso em persistir um estado de um objeto me vem o Memento do GoF na mente!
Sera que nao seria uma boa aplicacao para o memento?
Po mas o memento so tem dados dentro dele sera um : Anemic, Fantoche? Cade a coesao?
Sera que o memento fere a OO como o DTO o Comand??
Nao sei, mas ainda acho que memento seria uma boa pedida para persistir o estado de um objeto ainda mais porque ele mante a encapsulamento do objeto!
Aguardo a opiniao de vcs…
Alguem pode me passar o link do livro DDD citado pelo Kenobi?
[quote=brunohansen] Sempre que penso em persistir um estado de um objeto me vem o Memento do GoF na mente!
Sera que nao seria uma boa aplicacao para o memento? [/quote]
Lembro do Shoes ter comentado sobre este assunto. Fiz uma busca e encontrei isso:
http://www.guj.com.br/posts/list/15/28889.java
http://www.guj.com.br/posts/list/60/24210.java
[quote=Thiago Senna][quote=brunohansen] Sempre que penso em persistir um estado de um objeto me vem o Memento do GoF na mente!
Sera que nao seria uma boa aplicacao para o memento? [/quote]
Lembro do Shoes ter comentado sobre este assunto. Fiz uma busca e encontrei isso:
http://www.guj.com.br/posts/list/15/28889.java
http://www.guj.com.br/posts/list/60/24210.java[/quote]
Dei uma lida! Me pareceu que no inicio o shoes gostou da ideia de usar memento mas depois desaprovou por causa dos grandes sistema e da zona que eles se tornaram por causa dos mementos.
Mas nao vi nada de muito concreto! Sera que no mundo da engenharia de soft um dia vai existir algo de concreto?
[quote=Kenobi]Preciso começar a mudar a forma de pensar, que foram sendo injetadas na mente durante anos de Design Patterns publicados como boas práticas entre outros.
[/quote]
Fiquei confuso com essa reflexao!
Vc quer mudar a forma de pensar que os padroes te proporcionaram ?
Se sim pq?
Aee duende valew pelo link!!!
Bom, até onde eu aprendi, o conceito de OO difere da estrutural exatamente pelo motivo de existir Entidades com Responsabilidades.
Então, não acho que seja errado colocar métodos de negócio dentro de um Entity, desde que esse método seja realmente pertinente a ele.
Utilizar Business Class pra fazer todo o trabalho, acaba transformando os Entitys em simples VO’s, com a facilidade da persistência.
Claro que tb não vamos exagerar e sair colocando 500 métodos de negócio em um Entity, mais questões como Persistir, atualizar, cancelar e apagar, acho que seja legal sim.
Um outro conceito, se eu tenho uma Entidade chamada Predio, a qual agrega várias salas e apartamentos, pq não colocar um método para atualizar todas as salas dentro da entidade Prédio, ao invés de utilizar uma Business só para isso ?
Agente acaba tendo que instanciar sempre uma Business e uma Entity para fazer o trabalho que resolveríamos apenas com a Entity.
Já utilizei essa arquitetura (se não estou enganado, chamam de Active Record) em alguns projetos, e deram bastante resultado.
Agora, voltando ao problema inicial, tem como injetar o Session dentro do Entity no EJB3 ou terei que usar um bom e velho LookUp ?