Duvidas no MVC

Debugger Membro desde: 20/10/2006 11:52:17 Mensagens: 64 Offline

Oi Pessoal, vim do Delphi e nele não usávamos MVC, estou migrando pra Java(VRaptor3+Hibernate)/ExtJS, estou com duvidas na minha extrutura MVC:

Levando em consideração o cadastro de categorias os exemplos que vejo sempre funcionam assim:

Controller:
CategoriaController.java

Model:
CategoriaDao.java - As regra de negócio ficariam aqui.
Categoria.java

Neste caso, penso eu, que as regras de negócio(condições para poder ou não persistir a informação) ficarão nos métodos da classe CategoriaDao, o CategoriaController deve servir apenas como uma ponte entre o a View e o CategoriaDao.
Bom, ai vem a minha questão, a ideia de colocar regras no CategoriaDao me parece estranha, não seria melhor criar uma classe CategoriaServico e colocar minhas regras aqui?
Outra possiblidade que vejo é que se tratando do VRaptor(ao meu ver encapsula a camada de controle mesmo) poderíamos colocar na CategoriController e esta passaria a ter uma função de Model.

A Arquitetura que eu acho "mais correta" seria:

Controller:
CategoriaController.java

Model:
CategoriaServico.java - Aqui teria as lógicas e só chamaria a dao pra persistir mesmo
CategoriaDao.java
Categoria.java

Alguém saberia me dar uma luz?

Desde já, Obrigado.

Oi Sandro,

O MVC já sugere que voce trabalhe com 3 camadas (mínimo)

eu geralmente faço o seguinte

Categoria -> modelo
CategoriaDAO -> lógica para manipular dados no BD
CategoriaController -> recebe os dados da tela, trata, valida regras e se der td certo, repassa pro DAO
CategoriaTela -> entrada e saida de dados

no caso de ter uma classe serviço, qual seria a função do controler?

Então, há várias formas de resolver isso.
Mas, MVC não coloca regras de negócio na camada Model.
Se você optar por um service, precisará de classes do tipo TO/DTO (Transfer Object ou Data Transfer Object) para transitar os dados que vem da view até a model e vice versa.
Outra coisa, o service não estaria na camada model e sim, em um desdobramento de control.

Agora, não há razões para não fazer a parte lógica dentro do controller, afinal, é este seu objetivo.
Tratando-se de regra de negócio, independente de ser para persistir ou não, o controller é o responsável por isto.

Se você pesquisar ou um dia se deparar com struts 2, perceberá isso mais claramente.

drsmachado wrote:Tratando-se de regra de negócio, independente de ser para persistir ou não, o controller é o responsável por isto.

Como assim meu caro?

raf4ever wrote:

drsmachado wrote:Tratando-se de regra de negócio, independente de ser para persistir ou não, o controller é o responsável por isto.

Como assim meu caro?

Dentro do padrão MVC, a camda view só poderá conter o que for relacionado à interação com usuário.
Model, apenas o que for coerente com a persistência e, isso significa, que lógica de negócios, não.
Control vai englobar e aplicar todas as regras de negócios, independente do que elas representes.
Se for algo que irá afetar a camada view, como o case da fonte (upper ou lower) ou a persistência (só salva se o objeto não possuir nenhum campo vazio ou nulo), não importa, é o controller que irá gerenciar isso.

regras como validação de cpf, idade mínima... mais relacionado ao négocio que voce está automatizando e não tanto como valores obrigatórios que seria mais o caso de BD.

MaYaRa_SaN wrote:regras como validação de cpf, idade mínima... mais relacionado ao négocio que voce está automatizando e não tanto como valores obrigatórios que seria mais o caso de BD.

Não entendi direito o que você quis dizer, mas, se foi o que estou pensando, também discordo.

Validações devem ocorrer em todas as camadas.
Na view, para evitarmso coisas do tipo CPF 00000000000 ou 9999999999, campos de data com formato errado, campos numéricos com dígitos.
Caso alguma coisa passe (firebugs da vida), a camada control faz a revalidação, além de analisar um pouco mais a fundo (por exemplo, fazendo uso de frameworks, como o Stella).
A camada model só se preocuparia com a integridade do banco, atributos nulos, com tamanho maior que o permitido, enfim.

Isso dificilmente afeta ou está na lógica do negócio.

Concordo, as mascaras devem estar presentes nas interfaces para evitar digitação errada.

Mas na camada de controle as validações de tela devem estar redundantes e além delas, as regras de negócio e valores obrigatórios.

Quanto utilizo MVC, eu prefiro deixar a camada DAO apenas com a logica de manipulação de dados. assim meu sistema fica mais organizado, sem validaçoes espalhadas por todas as camadas, o que facilita a manutenção mais pra frente.

mas é apenas a minha opinião

Thread.start() Membro desde: 28/10/2011 10:08:40 Mensagens: 26 Offline

ae eu indico que estude mas jsf do que Vraptor, pois é o que esta sendo usado no maercado de trabalho ^^.

MaYaRa_SaN wrote:Concordo, as mascaras devem estar presentes nas interfaces para evitar digitação errada.

Mas na camada de controle as validações de tela devem estar redundantes e além delas, as regras de negócio e valores obrigatórios.

Quanto utilizo MVC, eu prefiro deixar a camada DAO apenas com a logica de manipulação de dados. assim meu sistema fica mais organizado, sem validaçoes espalhadas por todas as camadas, o que facilita a manutenção mais pra frente.

mas é apenas a minha opinião

Concordo plenamente.

Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema...

JavaBaby Membro desde: 03/05/2011 23:21:06 Mensagens: 88 Offline

Só pra efeito de consolidação de conceitos, sugiro a leitura desse artigo escrito pelo Phillip Calçado (Shoes): http://fragmental.com.br/wiki/index.php/MVC_e_Camadas.

O povo sempre confunde Camadas com MVC...

Debugger Membro desde: 20/10/2006 11:52:17 Mensagens: 64 Offline

drsmachado wrote:

MaYaRa_SaN wrote:Concordo, as mascaras devem estar presentes nas interfaces para evitar digitação errada.

Mas na camada de controle as validações de tela devem estar redundantes e além delas, as regras de negócio e valores obrigatórios.

Quanto utilizo MVC, eu prefiro deixar a camada DAO apenas com a logica de manipulação de dados. assim meu sistema fica mais organizado, sem validaçoes espalhadas por todas as camadas, o que facilita a manutenção mais pra frente.

mas é apenas a minha opinião

Concordo plenamente.

Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema...

É por isso que eu queria colocar uma classe que eu chamei de CategoriaServico, se um dia for mudar a view ou o próprio Vraptor, teria muito poucas alterações pra fazer...

Sempre vi o pessoal falando que a regras de negócio devem ficar no Model.

Sandro Mueller wrote:

drsmachado wrote:

MaYaRa_SaN wrote:Concordo, as mascaras devem estar presentes nas interfaces para evitar digitação errada.

Mas na camada de controle as validações de tela devem estar redundantes e além delas, as regras de negócio e valores obrigatórios.

Quanto utilizo MVC, eu prefiro deixar a camada DAO apenas com a logica de manipulação de dados. assim meu sistema fica mais organizado, sem validaçoes espalhadas por todas as camadas, o que facilita a manutenção mais pra frente.

mas é apenas a minha opinião

Concordo plenamente.

Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema...

É por isso que eu queria colocar uma classe que eu chamei de CategoriaServico, se um dia for mudar a view ou o próprio Vraptor, teria muito poucas alterações pra fazer...

Sempre vi o pessoal falando que a regras de negócio devem ficar no Model.

meodeos...

No model, não!!!

Debugger Membro desde: 20/10/2006 11:52:17 Mensagens: 64 Offline

drsmachado wrote:
meodeos...

No model, não!!!

Notar:
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
http://www.macoratti.net/vbn_mvc.htm
http://dpasqua.wordpress.com/2010/01/20/php-melhores-praticas-parte-1-mvc/
http://www.leonardomarques.net/site/ruby-on-rails-onde-colocar-as-regras-de-negocio.html
tem muito mais, estes foram os primeiros...

Sem falar que parece ser mais lógico colocar esta camada na Model, a Control esta indiretamente ligada ao View, se vc estiver trabalhando com aplicativos Web terá que trabalhar com requests ou um frameWork que encapsule, se for "desktop(local)", instanciará direto um controller que não trabalha com request, logo, se vc colocar a suas regras de negócio no Control terá que escrever um control pra Web com todas suas regras e outro pra "desktop(local)" novamente com suas regras, enquanto que se elas estivessem em uma camada/classe dentro da Model, teria apenas que implementar o "toma lá, da cá" do control...

Obs.:O Desktop(local) podeira acessar os dados via WebService, mas isto é outra história...

Não quero criar polêmica mas o correto me parece ser na Model, caso realmente tenha que ser na Control gostaria de saber o porque.

Sandro Mueller wrote:

drsmachado wrote:
meodeos...

No model, não!!!

Notar:
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
http://www.macoratti.net/vbn_mvc.htm
http://dpasqua.wordpress.com/2010/01/20/php-melhores-praticas-parte-1-mvc/
http://www.leonardomarques.net/site/ruby-on-rails-onde-colocar-as-regras-de-negocio.html
tem muito mais, estes foram os primeiros...

Sem falar que parece ser mais lógico colocar esta camada na Model, a Control esta indiretamente ligada ao View, se vc estiver trabalhando com aplicativos Web terá que trabalhar com requests ou um frameWork que encapsule, se for "desktop(local)", instanciará direto um controller que não trabalha com request, logo, se vc colocar a suas regras de negócio no Control terá que escrever um control pra Web com todas suas regras e outro pra "desktop(local)" novamente com suas regras, enquanto que se elas estivessem em uma camada/classe dentro da Model, teria apenas que implementar o "toma lá, da cá" do control...

Obs.:O Desktop(local) podeira acessar os dados via WebService, mas isto é outra história...

Não quero criar polêmica mas o correto me parece ser na Model, caso realmente tenha que ser na Control gostaria de saber o porque.

Nos casos em que o controller fica disposto na camada de apresentação, utilizamos DTOs para trafegar dados até o DAO e, isso é feito, através dos Services, que irão assimilar as funções do controller.
Em geral, aplicações corporativas seguem essa lógica.

Detalhe, para aplicações desktop, aceita-se uma pequena alteração, visto que, este tipo de projeto permite que algumas lógicas sejam implementadas na camada de apresentação (view).
Assim temos apenas duas camadas view/control e model.

Notícias, artigos e o maior fórum brasileiro sobre Java