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
Um exemplo de um metodo da action:
public String inserir() throws SQLException{
new ClienteDAO().inserir(this.cliente);
return SUCCESS;
}
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.
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.
[quote=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.
[quote=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![/quote]
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.
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?
[quote=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?
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.
[quote=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.
[/quote]
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.
[quote]
De qualquer forma, se fosse comigo, eu colocaria o método calcularIdade na classe Cliente.[/quote]
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.
