Qual a diferença entre model e controller?
Por exemplo, as classes que modelam objetos fazem parte do model ou do controller?
e as classes dos DAO’s?
Diferenciar Model e Controller
R
13 Respostas
C
O Controller é o cara que vai fazer a mediação entre tua view e teu domínio (Model).
Teu model é onde serão implementadas as RN do cliente.
Cara, isso que vc falou não tem muito sentido
Tirando as classes estáticas e abstratas, todas tem a ver com objetos.
Resumindo:
Model -> Resolve as RNs
Controller -> Servem como interface entre o “mundo Java” e o mundo “view”.
IMHO.
Abraços
S
Qual a diferença entre model e controller?
Model é o domínio da dua aplicação, onde as regras de negócio são implementas. Controllers coordenam o workflow, ou seja, a interação da interface com usuário e seu objetos de domínio.
O que são “classes que modelam objetos”?
e as classes dos DAO’s?
DAO fazem a persistência dos seus objetos de domínio. Consequentemente, não fazem parte do seus controllers, e de preferência também não devem estar associados diretamente a eles.
R
Classes que modelam objetos para mim são as classes onde tem os getters e setters
C
Classes que só tem getters e setters, normalmente, são chamadas de POJOs.
Pelo que andei lendo, também são VOs. Mas me parece (e compartilho dessa opnião) que esse tipo de denominação é desnecessária.
Abraços
R
Legal não sabia que elas eram chamadas de POJOs
Aproveitando o tópico, como vocês organizam o package de vocês?
Juntam as POJOs e os DAOs ou deixam em package separados?
C
Qual a diferença entre model e controller?Por exemplo, as classes que modelam objetos fazem parte do model ou do controller?
e as classes dos DAO’s?
Se vc esta falando de MVC (model-view-controller), tanto o model, o view e o controller fazem parte geralmente da mesma camada, geralmente apresentacao. Eles sao criados com o objetivo de separar as responsabilidades e facilitar a compreensao na interacao dos objetos. Por ser um padrao arquitetural a implementacao de MVC pode variar mas de forma geral o controller faz a ponte entre a view e o model, esse ultimo por sua vez delega solicitacoes à camada que reune as regras de negocio da sua aplicacao (dominio). Se nao ha uma camada de dominio definida ela acessa os DAOs diretamente.
Caso sua aplicacao possua uma camada de dominio onde as regras de negocio sao implementadas geralmente o banco de dados e seus objetos de acesso (DAOs) nao sao manipulados diretamente pela model do MVC, mas indiretamente. Nestes casos o model (do MVC) conhece apenas a interface do dominio, abstraindo qualquer coisa relacionada a banco de dados e infraestrutura de maneira geral.
C
Classes que só tem getters e setters, normalmente, são chamadas de POJOs.Pelo que andei lendo, também são VOs. Mas me parece (e compartilho dessa opnião) que esse tipo de denominação é desnecessária.
Abraços
Sei la deonde vc tirou essa definicao de POJOs mas ela esta equivocada. POJOs nao necessariamente possuem metodos gettters e setters.
A
oi,
um POJO é algo diferente de um Entity do EJB http://www.martinfowler.com/bliki/POJO.html
A
para entender um pouco o conceito de MVC de uma olhada nesta apostila, eu estou estudando ela agora, qualquer coisa estamos ai 
C
oi,um POJO é algo diferente de um Entity do EJB http://www.martinfowler.com/bliki/POJO.html
E quem falou que eles sao iguais?
C
Classes que só tem getters e setters, normalmente, são chamadas de POJOs.Pelo que andei lendo, também são VOs. Mas me parece (e compartilho dessa opnião) que esse tipo de denominação é desnecessária.
Abraços
Sei la deonde vc tirou essa definicao de POJOs mas ela esta equivocada. POJOs nao necessariamente possuem metodos gettters e setters.
Entendi. Então, presumo, você acessa seus atributos diretamente. Eu, particularmente, prefiro criar getters e setters.
Não creio que eu tenha definido POJO. Apenas disse que classes que contenham apenas atributos e seus respectivos getters e setters são POJOs. Ou estou errado?
C
Logo nao faz sentido o que vc escreveu…
POJOs PODEM ter getters e setters, mas nao é isso que o define.
O que vc esta chamando de POJO na verdade sao objetos que seguem a especificacao javabeans.
http://en.wikipedia.org/wiki/JavaBeans
http://en.wikipedia.org/wiki/Plain_Old_Java_Object
C
Cara, então. JavaBeans não podem ser considerados POJOs?
O segundo link que você passou diz que sim.
E mais uma vez: não defini POJO. Me referi a um tipo de classe que pode ser chamada de POJO. Ou um JavaBean não pode ser chamado de POJO??
Realmente não sei onde você está querendo chegar. Parece que estou falando alemão e você chinês.
Criado 20 de setembro de 2008
Ultima resposta 20 de set. de 2008
Respostas 13
Participantes 5