Duvidas no MVC

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.

Como assim meu caro?

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.

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 [telefone removido] ou [telefone removido], 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

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

MaYaRa_SaN:

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…

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…

drsmachado:

MaYaRa_SaN:

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:

drsmachado:

MaYaRa_SaN:

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.

No model, não!!!

drsmachado:

meodeos…

No model, não!!!

Notar:
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
http://www.macoratti.net/vbn_mvc.htm

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. 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:

drsmachado:

meodeos…

No model, não!!!

Notar:
http://fragmental.com.br/wiki/index.php/MVC_e_Camadas
http://www.macoratti.net/vbn_mvc.htm

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. 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.

Também tenho muita dúvida nessa parte.

Mas para mim
As regras de apresentação devem ficar na tela (
validações de campo preenchido e mascara etc.)

Na camada de controller
Creio que deva ficar apenas as regras de navegação(Redirecionamento)

Na model
devem ficar as regras de negócio e os bens .

Não sei se esse seria o padrão correto mas é o que tenho fixo na cabeça.(Talvez na tela fique apenas as mascaras e a validações de campos deva ficar no controller).

Honestamente não sei qual seria o melhor padrão, vo pegar um bom livro de padrões e dar uma fuçada na net para ver se concluo algumas coisa.

Basicamente o que eu penso é isso

view alguma tecnologia de renderização
JSP,JSTL,JSF,XHTML

controller alguma tecnologia capaz de capturar as requisição fazer algum tratamento se necessário e redirecionar
Actions e Servlet

Modelo
Beans
DAOs

Aqui ainda usamos algumas camadas a mais view,action,facade,model,dao

tenho muita dúvida aonde validar os dados de entrada , mas creio que as regras de negócio sejam mesmo na model

Correção não são camadas a mais…

São as tres camadas mas com responsabilidades divididas em mais classe.

Sandro, deve existir centenas de tópicos sobre MVC aqui no GUJ, respondendo e trazendo muitas outras dúvidas. Mas deve-se observar que:

1. MVC não é a respeito da divisão de camadas, portanto dizer que a regra de negócio fica no Model (ou Controller ou View) é estranho.

2. No Domain-Driven Design, existe uma sugestão para divisão de camadas, são elas: Apresentação, Atividade, Domínio e Infra-Estrutura. As regras de negócio estão no Domínio.

3. O padrão Repository faz parte do domínio. É uma coleção mais inteligente, pois “conhece” o domínio e apresenta métodos mais específicos (e não somente métodos genéricos).

4. Para implementar um Repository pode se utilizar um DAO. O DAO não faz parte do domínio, e sim da camada de infra-estrutura.

5. Você pode ter (e possivelmente terá) serviços que encapsulam a lógica da sua aplicação. Isso não significa que você não deve acessar um repository diretamente. Normalmente, quando você deseja somente realizar buscas simples, o acesso é feito direto no repositório, sem um serviço no meio.

Desse modo, o Controller (do VRaptor ou de outro framework) pode acessar tanto um Repository quanto um Service que está encapsulando uma determinada lógica.

Pra entender melhor, veja, por exemplo, o código do JForum 3:

Falou!

Pense sempre em simplificar as coisas, e não em adicionar camadas só por adicionar.

Eu geralmente uso assim:

Categoria: entidade + lógicas pertinentes ao modelo Categoria, e nada mais
CategoriaDao: somente os SQL’s e qualquer outra coisa que somente faça gravar e buscar meus dados. Só!
CategoriaController: server para redirecionar a chamada para o responsável certo, e de acordo com o resultado, escolher qual q melhor view e qual resultado deve ser apresentado para o usuário
CategoriaView: sua view, SWING, HTML ou qualquer outra coisa
CategoriaService: SOMENTE uso essa cama se tenho uma lógica um pouco mais que envolva MAIS de uma entidade.

Espero ter ajudado.

De maneira geral é exatamente o que o colega disse acima que eu penso.

E acho certo utilizar.

Já teve projeto que eu participei que tinham classes auxiliares de serviço para facilitar o trabalho com as
classes de negócio, tratar repostas mais complexas.

:twisted: