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
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?[/quote]
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 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.
[quote=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 :)[/quote]
Concordo plenamente.
Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema…
[quote=drsmachado][quote=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 :)[/quote]
Concordo plenamente.
Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema…[/quote]
É 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.
[quote=Sandro Mueller][quote=drsmachado][quote=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 :)[/quote]
Concordo plenamente.
Mesmo por que, a idéia do MVC é esta.
Se amanhã ele trocar de vRaptor para JSF, já vai ter muito problema…[/quote]
É 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. [/quote]
meodeos…
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.
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.[/quote]
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.
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.
Sandro, deve existir centenas de tópicos sobre MVC aqui no GUJ, respondendo e trazendo muitas outras dúvidas. Mas deve-se observar que:
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.
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.
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).
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.
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:
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.
Desktop(local) podeira acessar os dados via WebService, mas isto é outra história…