[quote=maazevedo]
Ah sim… mais uma coisa. Vocês podem me indicar livros que vocês já leram sobre o assunto…
Obrigado.[/quote]
Comece por esse e estara bem servido.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
]['s
Valeu fabgp2001…
Obrigado.
Boa sugestão do Fábio… Domain Driven Design é excelente. Sobre a persistência, use um DAO para colocar os métodos que você falou.
Bom, vamos devagar…
JavaBeans não são classes apenas de dados, são um modelo de componente falido da Sun. Hoje em dia um JavaBean é uma classe que obedece a convenção de métodos com nome de get/set, não diz [bnada[/b] sobre terem dados, lógica ou qualquer otura coisa.
Sobre “classes de daos x classes de lógica”, se algum livro menciona isso (fora do cotnexto EJB 2.x, por favor) me indique porque eu estou atraz desta literatura faz tempo.
Quanto á escalabilidade, ter classes de dados e de lógivca separados não vai ter ajudar. Classes de dados não são DTOs de verdade, DTOs são criados pensando em como otimizar tráfego por uma rede, não mapear conceitos de negócio. A Mundo java #15 fala disso .
Os outros questionamentos sobre o uso de objetos de verdade (“classes gordas”) e não structs não possuem argumentos. Por que haveria perda de desempenho? Não há problema de escalabilidade em utilizar objetos.
“Tudo que preciso são dos atributos” foge completamente aod esenvolvimento OO. O que você precisa, seja em qual camada for, é de objetos, e eventualmente mostrar alguma dimensão (um atributo, comaprando porcamente) do estado deste. Logo você passa o objeto e exibe a dimensão, sem maiores problemas.
A questão não é ‘ficar melhor estruturada do ponto de vista O.O.’ a questão é de que simplesmente se você não tem objetos possui estruturas de dados e funções, e se você possui estruturas de dados e funções você não está num sistema OO e sim num sistema procedural, exatamente como os construídos em Pascal ou C.
O tal ‘desperdício’ de criar objetos com métodos que não serão utilizados não procede. A JVm (assim como a maioria das plataformas) cria apenas uma vez o espaço destinado a código em memória, logo não há repetição não utilizada.
Leiam os artigos, eles trazem muitas informações sobre isso.
Olá pcalcado,
Quer dizer então que se eu tenho 20 objetos, eu tenho em memória o estado destes 20 objetos (diferentes valores para seus atributos), mas a área de código que é igual para todos os objetos (no nosso caso o código dos métodos) é alocado uma única vez?
Obrigado!
Sim. Os bytecodes são os mesmos para todas as instancias de uma dada classe.
Ainda bem que é assim, já pensou se tivessemos uma tela complexa feita em swing, com muitos botões por exemplo e cada um deles fosse um objeto separado? Imagina então se a máquina do usuário for um pentium 2 com 16MB de memória…
Desculpe a ignorância de minha parte, mas só pra matar as últimas dúvidas bestas que tenho sobre o assunto.
Implementando, corretamente a action do modo como foi comentado aqui e desprezando o modo como o framework carrega a classe de negócio, seria?
[code]
Cliente cliente = new Cliente();
… chamada aos setters para atributos de cliente
cliente.verificaPessoa();
ClienteDao dao = new ClienteDao();
dao.save(cliente);[/code]
ou
[code]
Cliente cliente = new Cliente();
… chamada aos setters para atributos de cliente
cliente.verificaPessoa();
ClienteDao dao = new ClienteDao();
cliente.save(dao);[/code]
1º) Qual seria o mais correto do ponto de vista OO?
2º) Se Cliente salvar a si mesmo não ficaria atrelado esse a metodo ‘save’ da interface do dao?
Minha dúvida é similar à do amigo que postou acima…
Se eu deixar que meu bean cuide tbm das regras de negócio, é correto então instanciar o DAO dentro do bean? Se não for essa a maneira correta, qual seria? Existem alternativas?
Obrigado!
Eu particularmente não gosto muito da idéia de criar uma dependência da classe de dominio com o DAO, portanto escolheria dao.save(cliente). Mas isso é questão de persistência e não regra de negócio.
[quote=David]Eu particularmente não gosto muito da idéia de criar uma dependência da classe de dominio com o DAO, portanto escolheria dao.save(cliente). Mas isso é questão de persistência e não regra de negócio.
[/quote]
Mas eu faria algo assim?
public class MinhaClasse{
//atributos
//getters and setters
//public String save(){
MeuDAO dao = new MeuDAO();
//mais código...
dao.save(this);
//mais código...
}
}Quer dizer, é correto instanciar o DAO dentro da classe ?
O que me intriga é o caso dos fantoches que o Phillip menciona, daí parto para o pré-suposto de que o save deveria pertencer ao cliente, mas logo se passo um dao pra ele crio um acoplamento do meu objeto de negócio com a interface de persistência.
Mas pensando por outro lado, não estaria preso à uma classe Dao em si, somente à interface disponível, ou seja, o meio de comunicação a qual meu objeto precisa saber para salvar a si mesmo, daí independe se vai ser persistido em banco de dados relacional, arquivo XML ou outro meio.
Será que essa linha de pensamento poderia ser considerada como viável?
Sua reusabilidade poderia ser menor do que no caso dao.save(cliente), onde a classe Cliente é independente e poderia ser reutilizada em qualquer outro projeto.
Phillip? David?
P.S.: O assunto parece estar fugindo do tópico, mas se perceberem ele é complementar ao MVC porque o que estamos discutindo é praticamente o que fica na Action, e pergunta do criador do tópico foi “… qual é a forma mais elegante de se dividir a aplicação ?”
Ao meu ver na action deve existir APENAS o controle da aplicação, isso é, para onde o usuário é direcionado a cada intereção com o aplicativo, o que acontece com a camada de apresentação, quais componentes são chamados, etc. Eu ainda tenho dúvidas quanto a ter regras de negócio nos meus beans, entretanto tenho certeza de que regra de negócio na action não pode!
Calma calma, saímos do projeto e chegamos á arquitetura do sistema.
Todas as dúvidas quanto a “objetos de lógica” e “objetos de dados” serem ruins sanadas?
Próximo passo: Camadas.
Apresentação, Negócios e Persistência são geralmente implementadas como Camadas diferentes. Dêem uma olhada nestes slides e procurem a MundoJava #15.
Quanto ao DAO, existem duas estratégias básicas: DataMapper e ActiveRecord. As duas têm utilizade mas geralmente o Mapper é preferida. para abstrair o DAO pode-se utilizar um repositório, mais detalhes MundoJava #17 ou uma busca por domain driven design (tem um post recente sobre isso no meu blog).
Que susto levei aqui! VO é um objeto burro?
Tudo bem estou mais acostumado com o VO do Fowler que diz: Um objeto pequeno e simples, como dinheiro ou intervalo de datas, cuja a igualdade não é baseada em identidade e sim em valores.
Repare que no artigo do shoes ele disse:
Um dos padrões deste catálogo era chamado de Value Object, ou VO. Posteriormente este objeto foi renomeado para Transfer Object por haver um conflito de nomes dele e outro padrão (interessante notar que a documentação oficial ainda faz uso do nome antigo nos diagramas) e porque trata-se de uma adaptação do padrão Data Transfer Object, também do Fowler.
O VO antes chamado pela Sun hj é Transfer Object. (Esse sim é meio burro mas pode ser utilizado bem em comunicação de redes).
O VO do Fowler não tem nada de burro!
Resumo bom do livro DDD http://www.infoq.com/minibooks/domain-driven-design-quickly
[]s