olá pessoal
estou construindo um projeto usando mvc, utilizo o hibernate para a persistencia dos dados e uma duvida surgiu, quando eu vou inserir uma informação no banco de dados antes de faze-lá eu verifico se ela já está cadastrada, se não estiver eu cadastro, caso contrário retorno que já está cadastrada, a questão é: essa verificação se o registro já existe deve ser implementada na camada de persistencia ou de negocio?
vlw.
entao cara isso depende da sua implementaçao mais geralmente verificamos se ja existe senao atualizar no hibernate tem ate um metodo pronto insertOrUpdate se nao me engano na hora de persistir.
Opa,
Você deverá implementar essa regra dentro da camada de negócio.
Abraço
Antes de prosseguir será que você poderia definir para nós o que você entende por “camada de persistência e camada de negócios” e onde isso se encaixa no MVC?
Abraços.
a camada de persistencia são os meus DAOs que manipulam os dados do banco de dados, a camada de negocios é a minha logica do sistema em si
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
A grosso modo:
M - Model: sua “camada” de lógica de negócios, nele há o sistema em si, o que ele faz, as “sub-camadas” de acesso a dados, envio de sms, políticas de segurança, enfim, o core, núcleo do seu sistema. Lógico que completamente independente de visualizações e com interfaces de acesso público coerentes e consistentes.
V - View : representação gráfica do seu model, como o seu model deve ser parecer graficamente. Note que é normal e obrigatório que seu view saiba como o model funcione, mas o inverso jamais deve acontecer.
C - Controler: ai que o bixo pega, acredito que o nome desse cara tenha sido muito mau escolhido, o que alimenta ainda mais essa má interpretação. Esse cara aqui faz as pequenas lógicas de conversões e comunicação entre a view e o model. Esse cara nao deve conter nunca lógica de negócios, apenas a comunicação entre as outras “camadas”. Costuma-se dizer que Controler e View estão intimamente ligadas e isso é a mais pura verdade, pra cada view temos um controler que jamais será reaproveitado, lembre-se: pra cada view temos o respectivo controler (nao necessariamente apenas um, depende da complexidade da view).
Note que a única coisa que você “reaproveita” é o model, que é onde contem toda a lógica, que é o que representa o sistema puro e simplesmente, com suas sub-camadas de persistência e tudo mais. Jamais reapriveita-se view e controler
ps: jaja vai aparecer alguém pra dizer que não se deve chamar isso de camada, deixo a essas pessoas explicarem por que mas usei em analogia.
ps2: há mais coisas a se abordar do que eu disse.
ps3: sim, eu sei que foi um choque descobrir que o seu conceito de MVC estava errado, foi assim comigo…
ps4: to procurando uns links legais aqui pra postar
ps5: ta bom ja neh?
Abraços!
[quote=Tchello][quote]
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
[/quote]
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
[/quote]
valeu pela explicação, se vc não fala eu ir continuar a falar errado, rsrsrs
mas só o Fasagri respondeu eu tenho que implementar a verificação na camada de negocios então e não no meu DAO?
[quote=cvinicios][quote=Tchello][quote]
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
[/quote]
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
[/quote]
valeu pela explicação, se vc não fala eu ir continuar a falar errado, rsrsrs
mas só o Fasagri respondeu eu tenho que implementar a verificação na camada de negocios então e não no meu DAO?[/quote]
Por ai mesmo.
O seu DAO é parte da camada de persistência que faz parte do seu Model, correto?
Então quem tem que verificar aquilo é sua camada de negócios, portando o model, seja pedindo informações a camada de persistencia (DAOs) ou não.
Quanto a má interpretação, como eu disse antes, acredito que esse seja o erro mais comum. Ontem mesmo estava discutindo com um colega e chutei (chutômetro mesmo) que uns 80% das pessoas que acham que sabem MVC não sabem MVC tendo justamente essa interpretação que você teve.
O que é perfeitamente comum, mas agora que já avisamos recomendo uma boa leitura sobre e bastante reflexão sobre o tema.
ps: cuidado com blogs que “explicações” e “tutoriais”, procure fugir dessas figuras, há muitos blogs de moleques que não tem a menor noção do que estão fazendo e saem publicando qualquer besteira. Há sim uns muito bons e muito bem explicados, mas para identifica-los seja bastante criterioso.
Abraços.
[quote=Tchello][quote=cvinicios][quote=Tchello][quote]
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
[/quote]
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
[/quote]
valeu pela explicação, se vc não fala eu ir continuar a falar errado, rsrsrs
mas só o Fasagri respondeu eu tenho que implementar a verificação na camada de negocios então e não no meu DAO?[/quote]
Por ai mesmo.
O seu DAO é parte da camada de persistência que faz parte do seu Model, correto?
Então quem tem que verificar aquilo é sua camada de negócios, portando o model, seja pedindo informações a camada de persistencia (DAOs) ou não.
Quanto a má interpretação, como eu disse antes, acredito que esse seja o erro mais comum. Ontem mesmo estava discutindo com um colega e chutei (chutômetro mesmo) que uns 80% das pessoas que acham que sabem MVC não sabem MVC tendo justamente essa interpretação que você teve.
O que é perfeitamente comum, mas agora que já avisamos recomendo uma boa leitura sobre e bastante reflexão sobre o tema.
ps: cuidado com blogs que “explicações” e “tutoriais”, procure fugir dessas figuras, há muitos blogs de moleques que não tem a menor noção do que estão fazendo e saem publicando qualquer besteira. Há sim uns muito bons e muito bem explicados, mas para identifica-los seja bastante criterioso.
Abraços.[/quote]
Na minha opinião isso é discutivel onde fica cada coisa…
Eu ja não vejo como uma coisa legal deixar validações no seu “model” ou no seu “dao” pra mim o controlador deve validar esse tipo de coisa ja que ele é feito pra isso mesmo conectar as duas pontas eu e muuuita gente implementa validações no controlador e nao porque ta errado , tem coisa que de se bater o olho ja se acha legal ou estranho pra mim as distinções de camadas são as seguintes.
Models - Implementam as classes e suas relações. Ex. Pai tem varios filho tem varias empresas que possui um gerente e blablabla…
Daos - Realizam as ações relativas as classes. Suas buscas,inserts,updates consultas complexas mas não implementam regra algumas pois o padrão ja diz DATA ACESS OBJECT ou seja não há motivo pra se implementar regra alguma aqui.
Controller - Utiliza seus dados para fazer as ações e implementa as regras.
Utilizando seus daos como camada de acesso.
View - Essa é a mais explicita . Implementa apenas regras de view (se campo deve aparecer ou nao,pode implementar regras de conta não tem problema algum)
Eu acho usando essas camadas um jeito legal de se trabalhar com MVC cada camada tem sua responsabilidade explicita.
Não fazem nada alem do que são propostas a fazer!!
[quote=boneazul][quote=Tchello][quote=cvinicios][quote=Tchello][quote]
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
[/quote]
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
[/quote]
valeu pela explicação, se vc não fala eu ir continuar a falar errado, rsrsrs
mas só o Fasagri respondeu eu tenho que implementar a verificação na camada de negocios então e não no meu DAO?[/quote]
Por ai mesmo.
O seu DAO é parte da camada de persistência que faz parte do seu Model, correto?
Então quem tem que verificar aquilo é sua camada de negócios, portando o model, seja pedindo informações a camada de persistencia (DAOs) ou não.
Quanto a má interpretação, como eu disse antes, acredito que esse seja o erro mais comum. Ontem mesmo estava discutindo com um colega e chutei (chutômetro mesmo) que uns 80% das pessoas que acham que sabem MVC não sabem MVC tendo justamente essa interpretação que você teve.
O que é perfeitamente comum, mas agora que já avisamos recomendo uma boa leitura sobre e bastante reflexão sobre o tema.
ps: cuidado com blogs que “explicações” e “tutoriais”, procure fugir dessas figuras, há muitos blogs de moleques que não tem a menor noção do que estão fazendo e saem publicando qualquer besteira. Há sim uns muito bons e muito bem explicados, mas para identifica-los seja bastante criterioso.
Abraços.[/quote]
Na minha opinião isso é discutivel onde fica cada coisa…
Eu ja não vejo como uma coisa legal deixar validações no seu “model” ou no seu “dao” pra mim o controlador deve validar esse tipo de coisa ja que ele é feito pra isso mesmo conectar as duas pontas eu e muuuita gente implementa validações no controlador e nao porque ta errado , tem coisa que de se bater o olho ja se acha legal ou estranho pra mim as distinções de camadas são as seguintes.
Models - Implementam as classes e suas relações. Ex. Pai tem varios filho tem varias empresas que possui um gerente e blablabla…
Daos - Realizam as ações relativas as classes. Suas buscas,inserts,updates consultas complexas mas não implementam regra algumas pois o padrão ja diz DATA ACESS OBJECT ou seja não há motivo pra se implementar regra alguma aqui.
Controller - Utiliza seus dados para fazer as ações e implementa as regras.
Utilizando seus daos como camada de acesso.
View - Essa é a mais explicita . Implementa apenas regras de view (se campo deve aparecer ou nao,pode implementar regras de conta não tem problema algum)
Eu acho usando essas camadas um jeito legal de se trabalhar com MVC cada camada tem sua responsabilidade explicita.
Não fazem nada alem do que são propostas a fazer!![/quote]
Discordo em alguns pontos.
O Controler pode sim fazer validações, mas o MODEL deve ser consistente ao ponto se por acaso receber alguma dado invalidado poder retornar um erro, pois ele é o sistema, ele é a parte que sabe o que pode e o que não pode. O Controler e a View se espelham nele e fazem a sua representação gráfica e de interação.
Digo isso por que o sistema em sí é o model e não deve depender de “implementações particulares” (controlers e views) para ser consistente.
E sim, o DAO (se você for usar um DAO) cuida apenas de acesso a dados, mas esse faz parte do MODEL.
[quote=Tchello][quote]
M - model = Modelo de Dados
V - View - (Interface com o usuario)
C - Controller - Controle (Camada de Negocios)
[/quote]
PEEEEHH! Errado!
Não se preocupe, esse é um dos erros mais comum de interpretação, eu diria até o maior de todos dentro os padrões existentes.
A grosso modo:
M - Model: sua “camada” de lógica de negócios, nele há o sistema em si, o que ele faz, as “sub-camadas” de acesso a dados, envio de sms, políticas de segurança, enfim, o core, núcleo do seu sistema. Lógico que completamente independente de visualizações e com interfaces de acesso público coerentes e consistentes.
V - View : representação gráfica do seu model, como o seu model deve ser parecer graficamente. Note que é normal e obrigatório que seu view saiba como o model funcione, mas o inverso jamais deve acontecer.
C - Controler: ai que o bixo pega, acredito que o nome desse cara tenha sido muito mau escolhido, o que alimenta ainda mais essa má interpretação. Esse cara aqui faz as pequenas lógicas de conversões e comunicação entre a view e o model. Esse cara nao deve conter nunca lógica de negócios, apenas a comunicação entre as outras “camadas”. Costuma-se dizer que Controler e View estão intimamente ligadas e isso é a mais pura verdade, pra cada view temos um controler que jamais será reaproveitado, lembre-se: pra cada view temos o respectivo controler (nao necessariamente apenas um, depende da complexidade da view).
Note que a única coisa que você “reaproveita” é o model, que é onde contem toda a lógica, que é o que representa o sistema puro e simplesmente, com suas sub-camadas de persistência e tudo mais. Jamais reapriveita-se view e controler
ps: jaja vai aparecer alguém pra dizer que não se deve chamar isso de camada, deixo a essas pessoas explicarem por que mas usei em analogia.
ps2: há mais coisas a se abordar do que eu disse.
ps3: sim, eu sei que foi um choque descobrir que o seu conceito de MVC estava errado, foi assim comigo…
[/quote]
Hum… o seu conceito continua errado.
O DAO não faz parte do model.
MVC não é separação em camadas. DAO faz parte da camada de persistência, não do model.
A separação em camadas chama-se arquitetura (de camadas)! não se chama modelo MVC.
A arquitetura de camadas (andares) pode dividir-se em 2, 3, 4, 5, 6, 10 , 20 … qualquer numero de camadas. Tudo depende dos nosso objetivos.
Numa aplicação web normal existem 5 camadas : cliente (browser) , apresentação (jsp/Servlets e actions) , Negocio (servicos), Integração (hibernate, dao) e Recursos (arquivos e banco de dados). “Integração” pode ser chamada de persistencia se os recursos são apenas um banco de dados, o que é comum.
Depende do que vc quiser fazer. Se vc quiser dar uma mensagem ao usuário que aquele cadastro já existe, vc precisa verificar isso explicaitamente na sua camada de negocio. A camada de persistencia apenas irá prover a mecanica para isso ( um select da vida) , mas a responsabilidade é da camada de negocio sendo que mostrar a mesagem é uma regra de negocios.
Se vc está pensando apenas em termos programáticos em que o sistema decide sozinho se faz o insert ou o update, então isso é responsabilidade apenas da camada de persistencia e como foi dito usam-se métodos como o insertOrUpdate() ou o save() do JPA que por baixo dos panos fazem essas verificações.
Tudo depende das suas regras.
Era exatamente o que eu disse que aconteceria e exatamente o que eu queria: alguém explicar o conceito correto de camadas.
Eu sempre me embanano com isso.
Obrigado Sérgio.
Há algum material a respeito que recomenda para leitura?
Abraços.
[quote=Tchello] Era exatamente o que eu disse que aconteceria e exatamente o que eu queria: alguém explicar o conceito correto de camadas.
Eu sempre me embanano com isso.
Obrigado Sérgio.
Há algum material a respeito que recomenda para leitura?
.[/quote]
Foi vc que pediu … 
http://www.javabuilding.com/architecture/introduction.html
http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/
Essas dúvidas de MVC são normais.
Respondendo a perguntou que originou o tópico: a validação é realizada no Modelo.
Na página 14 em diante deste tópico a sua pergunta é respondida com código exemplo.
Espero ter colaborado com seus estudos. Abraço.