Estou desenvolvendo uma aplicação utilizando MVC com struts2. Estou com uma duvida na implementação da camada de negocio.
Minhas classes estao distribuidas desse forma:
Cliente - POJO
ClienteAction - Metodos que utilzam a Classe DAO, passando como parametro uma instancia Cliente (pojo)
ClienteDAO - Metodos que efetivamente acessam o Banco
Posso chamar da minha action um DAO ou devo criar algo parecido com este artigo: http://struts.apache.org/2.x/docs/struts-2-spring-2-jpa-ajax.html . No caso desse artigo, eu teria uma classe chamada ClienteService ou GerenciadorCliente ou algo similar que teria como objetivo receber um Cliente da Action e repassar para o DAO. No meu projeto estou tratando a Action como se fosse a minha camada de negocios.
Nao vejo problema algum desde que nenhuma regra seja colocada no action. Se o que voce for fazer é realmente apenas chamar o metodo inserir do dao, nao ha problema, uma camada a mais ai é frescura.
Mas qualquer outra validacao que possa haver seria melhor criar um service sim, por exemplo se antes de inserir voce vai verificar se ja existe o cliente, ou se o credito do cliente esta liberado, é melhor por um service pra separar bem o que é apresentacao do que é negocio, pois as coisas tendem a crescer e ficarem confusas.
Em operacoes simples como a que voce mostrou, eu considero perda de tempo, mas ha quem discorde de mim.
R
robsonsilvar
Concordo com o que vc flw. Mas assim como eu coloquei um exemplo simples, creio que existirão metodos mais complexos que esses, como os que vc citou, de “verificar se ja existe o cliente antes de inserir, ou se o credito do cliente esta liberado”. A capa desse livro (http://www.infoq.com/resource/minibooks/starting-struts2/en/cover/coverlandingpage.jpg) me fez pensar que a action faz parte do model e por faz parte, a logica de negocios(“verificar se ja existe o cliente, ou se o credito do cliente esta liberado” ) poderia ser feito dentro da action.
Vou tratar de colocar um ClienteService na aplicação para evitar logica de negocio na action.
Vlw!
R
robsonsilvar
robsonsilvar:
Concordo com o que vc flw. Mas assim como eu coloquei um exemplo simples, creio que existirão metodos mais complexos que esses, como os que vc citou, de “verificar se ja existe o cliente antes de inserir, ou se o credito do cliente esta liberado”. A capa desse livro (http://www.infoq.com/resource/minibooks/starting-struts2/en/cover/coverlandingpage.jpg) me fez pensar que a action fazer parte do model e por faz parte, a logica de negocios(“verificar se ja existe o cliente, ou se o credito do cliente esta liberado” ) poderia ser feito dentro da action.
Vou tratar de colocar um ClienteService na aplicação para evitar logica de negocio na action.
Vlw!
Y
YvGa
robsonsilvar:
Concordo com o que vc flw. Mas assim como eu coloquei um exemplo simples, creio que existirão metodos mais complexos que esses, como os que vc citou, de “verificar se ja existe o cliente antes de inserir, ou se o credito do cliente esta liberado”. A capa desse livro (http://www.infoq.com/resource/minibooks/starting-struts2/en/cover/coverlandingpage.jpg) me fez pensar que a action faz parte do model e por faz parte, a logica de negocios(“verificar se ja existe o cliente, ou se o credito do cliente esta liberado” ) poderia ser feito dentro da action.
Vou tratar de colocar um ClienteService na aplicação para evitar logica de negocio na action.
Vlw!
Mesmo considerando que o Action faz parte do Model, nao significa que ele faz parte da logica de negocios. De novo deve ser dito que MVC é diferente de apresentacao/dominio/persistencia. Pondo regra de negocio na action voce esta acoplando sua aplicacao ao struts.
Model é tudo aquilo que nao é view na aplicacao (considerando que o servlet do struts é o controller), a regra de negocios (dominio) é uma parte do model. Fazer parte do model nao significa que faz parte da logica de negocios.
R
robsonsilvar
blz
vlw pela dica!
R
robsonsilvar
A classe que representa a camada de negocio geralmente possui metodos identicos ao da camada de acesso a dados com objetivo (obvio) de receber um resultado vindo do banco. Posso usar a camada de negocio para usar em outras situações alem de resultados de banco?
Ex: um metodo (coerente) na classe cliente que tem a seguinte assinatura:
public int calcularIdade(date dataNascimento) {
return date.now() - dataNascimento;
}
Não há acesso ao banco nesse metodo, devo colocar esse metodo na classe de negocio mesmo ou ela ficaria em outro lugar?
abraços!
R
robsonsilvar
robsonsilvar:
A classe que representa a camada de negocio geralmente possui metodos identicos ao da camada de acesso a dados com objetivo (obvio) de receber um resultado vindo do banco. Posso usar a camada de negocio para usar em outras situações alem de resultados de banco?
Ex: um metodo (coerente) na classe cliente que tem a seguinte assinatura:
public int calcularIdadeCliente(date dataNascimento) {
return date.now() - dataNascimento;
}
Não há acesso ao banco nesse metodo, devo colocar esse metodo na classe de negocio mesmo ou ela ficaria em outro lugar?
abraços!
Andre_Brito
Eu não entendo muito disso, mas queria dar meus 2 centavos.
Li em um artigo do Shoes, no bliki, pra não ter objetos burros, ou algo assim (o nome do artigo é Fantoches, se não me falha a memória). Apesar de que POJO com alguma coisa inteligente dentro não me parece algo sensato. Gostaria que alguém comentasse algo sobre isso.
De qualquer forma, se fosse comigo, eu colocaria o método calcularIdade na classe Cliente.
Y
YvGa
Andre Brito:
Eu não entendo muito disso, mas queria dar meus 2 centavos.
Li em um artigo do Shoes, no bliki, pra não ter objetos burros, ou algo assim (o nome do artigo é Fantoches, se não me falha a memória). Apesar de que POJO com alguma coisa inteligente dentro não me parece algo sensato. Gostaria que alguém comentasse algo sobre isso.
Na verdade o termo POJO surgiu de uma brincadeira, ironizando objetos com “titulos” como Enterprise JavaBean, JavaBean etc… Entao foi criado o termo POJO (plain old java object) que numa traducao livre significa “o bom e velho objeto Java”. O pessoal gostou do termo e ele se difundiu, mas no fundo ele é apenas um objeto normal, portanto dizer que “POJO com alguma coisa inteligente dentro não me parece algo sensato” soa estranho. Sim, eles podem e devem ser inteligentes.
De qualquer forma, se fosse comigo, eu colocaria o método calcularIdade na classe Cliente.
Sim, sem duvida deve ficar na propria classe Cliente já que é ela, e só ela, que possui as informacoes necessarias para calcular sua idade.
Esse é um dos pontos mais dificeis, e na minha opiniao, de longe o mais importante da orientacao a objetos. Responsabilidade. Mas nem sempre é tao simples de determinar a responsabilidade de um objeto como nesse exemplo.
