MVC...Am i doing this right? [Resolvido]

Olá pessoal, mais uma dúvida de um iniciante sobre MVC pra incomodar todo mundo…olhei uns 4 tutorias, uns 2 exemplos e uns 1234115 tópicos aqui no guj falando sobre o bendito e ainda continuo não tendo certeza se a minha conclusão está correta.

Minha “Arquitetura”(pacotes) ficou mais ou menos assim…

modelo.entidades (exemplo de classe: Contato) > Aqui fiz minhas entidades JPA(tô usando hibernate)

@Entity
public class Contato implements Serializable
{
	private static final long serialVersionUID = 123;

	@Id
	@GeneratedValue
	private Integer codigo;

	private String email;
	private String telefone1;
	private String telefone2;
    //getters,setter,equals,hash,tostring

modelo.dao (exemplo de classe: ContatoDAO) > Aqui vão as operações com o banco de dados

public class ContatoDAO
{	
	public String salvar(Contato entrada){
		//faz operação com o banco
	}
    //outros métodos (CRUD)

modelo.dao.util > Aqui fica a classe de conexão e o arquivo hibernate.cfg.xml

controle (exemplo de classe: ContatoController) > Aqui ficam as regras de negócio

public class ContatoController
{	
	
	public String salvar(Contato entrada){
		//alguma regra
		//joga pro DAO		
	}
    //outras regras

view (exemplo de classe: CadastroContato) > Aqui ficam os ManagedBeans, que só fazem pegar os dados da tela e jogar pro controller

@ManagedBean
public class CadastroContato
{	
	Contato contato;
	
	public String salvar(){
		//joga dados pro controller	
	}
    //getters,setters,outros métodos

Desde já agradeço a colaboração com um mero aprendiz.

Errado. Regras de negocio vão no modelo.

Errado. Regras de negocio vão no modelo. [/quote]

Diego,
Então as regras eu coloco em uma Classe no pacote “modelo.regras”? Não parece certo juntar as regras com o DAO.

E o que exatamente faz o papel do controle? Seria o MBean e o view fica sendo as páginas(xhtml) em si?

Obrigado.

Errado. Regras de negocio vão no modelo. [/quote]
[2]

Errado. Regras de negocio vão no modelo. [/quote]

Diego,
Então as regras eu coloco em uma Classe no pacote “modelo.regras”? Não parece certo juntar as regras com o DAO.

E o que exatamente faz o papel do controle? Seria o MBean e o view fica sendo as páginas(xhtml) em si?

Obrigado.[/quote]

Por exemplo, se você tem um sistema financeiro e nele você tem inúmeros métodos de cálculos. Os cálculos seriam regras de negócios e ficam no modelo. Eu costumo usar o pacote chamado service para isso. O Dao eu costumo chamar no service, assim, no controller tenho acesso ao dao pelo service.

O controller é apenas o intermediador entre view e model. E para acessar o model pelo controller, use o service( regras de negocio ). No controller você também pode chamar algum tipo de lógica de validação de interface, caso seja feita por código e não por javascript.

romarcio,
A única coisa que me resta entender é o papel do ManagedBean nesse baile. Ele faz parte do controle(Já que tem contato direto com as regras E com os dados da view)?

Ou ele é parte do modelo junto com a entidade JPA? Nesse caso o Faces Servlet é o controle?

Obrigado.

public class ContatoDAO { public String salvar(Contato entrada){

Porque esse salvar retorna uma String? Está com cara de estar errado isso…

O managedbean age como se fosse um “View Controller” ou seja, o objetivo dele é controlar os dados obtidos na view e passa para a camada de negócio. E o camada “Service” (também chamada de BO - Business Object) seria o que alguns chamam de “Business Controller” aqui sim ficariam as regras de negócio.

Ao meu entender o seu View Controller é a classe CadastroContato, o seu Business Controller (regra de negócio) é o ContatoController. É um padrão que considero bom fica bem dividido a regra de negócio do Managedbean, talvez fosse interessante mudar a nomenclatura para evitar confusão.

[quote=rogelgarcia]public class ContatoDAO { public String salvar(Contato entrada){

Porque esse salvar retorna uma String? Está com cara de estar errado isso…[/quote]
Ah, nem repare nisso (rs), fui fazendo o post na base no copy/paste, minha dúvida é mais dos conceitos gerais mesmo.

Att

Não tenho muita experiência no assunto, mas vc deveria deixar sua regra no seu objeto de dominio!

Há diversas formas de vc implementar uma estrutura MVC, mas uma boa prática é vc deixar regras no objeto de domínio e não na sua Action ou na Camada Service

vc pode usar a camada Service como diz o romarcio! mas essa camada muitas das vezes pode ser evitada! Muitos sistemas tem a camada Service que apenas redireciona para o DAO e que tem lógica que não deveria estar ali, tem que ser analisada se realmente precisa ter uma camada service!

Se a sua Session está a nível de request, por exemplo, mata o sentido de ter uma camada service no seu sistema!

Muitas vezes criamos a camada Service para add regras que deveriam, segundo o DDD, ficar nos próprios objetos de domínio.

Abrass

[quote]Diego,
Então as regras eu coloco em uma Classe no pacote “modelo.regras”? Não parece certo juntar as regras com o DAO.

E o que exatamente faz o papel do controle? Seria o MBean e o view fica sendo as páginas(xhtml) em si?

Obrigado[/quote]

Dao deve estar em uma camada diferente da de modelo, DAO é abstração do seu acesso ao banco, faz parte da camada de infraestrutura. A questão é, se você estiver utilizando um ORM (ou algo que tenha a mesma função) você não precisa de um DAO. Simplesmente o que você precisa é utilizar o seu ORM favorito (JPA, Hibernate, whatever) como um DomainStore e implementar o padrão Repository. Como fazer isso? Da uma olhada no blog do Sergio, que la tem N toques sobre esse assunto… Pode começar por aqui: http://sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/

[quote=leonardogamba]Olá pessoal, mais uma dúvida de um iniciante sobre MVC pra incomodar todo mundo…olhei uns 4 tutorias, uns 2 exemplos e uns 1234115 tópicos aqui no guj falando sobre o bendito e ainda continuo não tendo certeza se a minha conclusão está correta.

Minha “Arquitetura”(pacotes) ficou mais ou menos assim…

[/quote]

é mentira que vc leu os 1234115 topicos sobre o assunto. Ou vc teria lido que MVC NÂO É SEPARAÇÂO DE CAMADAS!

Porque raios é tão difícil as pessoas entenderem isto ?

Se quer conversar sobre separação camadas chame o topico de “Separação de Camadas … estou fazendo certo?”
Se quer conversar sobre separação de pacotes chame o topico de “Separação de Pacotes … estou fazendo certo?”
Se quer conversar de MVC não fale de pacotes.

Como separação de pacotes está ok. Vá em frente.

Bem, vamos tentar exemplificar…

Model - Suas entidades e seu DAO - Aqui você possui todo o modelo de dados, suas entidades como elas serão persistidas/consultadas/alteradas e coisas do tipo.

View - Aqui estão suas páginas ou sua tela.

Controller - Aqui está a classe intermediária, no caso do JSF, são os seus beans, nele você coloca suas regras e tudo mais.

O ideal é você criar mais uma camada, tipo uma camada de Serviço, onde você coloca todas as validações necessárias e no seu Controller, no caso, o seu bean, só pequenas validações e mensagens p/ tela.

Depois de uma olhadinha:

http://wehavescience.wordpress.com/2012/11/02/um-pouco-sobre-mvc-para-web/

E você também pode estar olhando esta aplicação que está no padrão MVC, ela é pequena, simples e de fácil entendimento.

Espero que tenha ajudado. :wink:

Bons estudos!

[]'s

[quote=kcobainnn]Bem, vamos tentar exemplificar…

Model - Suas entidades e seu DAO - Aqui você possui todo o modelo de dados, suas entidades como elas serão persistidas/consultadas/alteradas e coisas do tipo.

View - Aqui estão suas páginas ou sua tela.

Controller - Aqui está a classe intermediária, no caso do JSF, são os seus beans, nele você coloca suas regras e tudo mais.

O ideal é você criar mais uma camada, tipo uma camada de Serviço, onde você coloca todas as validações necessárias e no seu Controller, no caso, o seu bean, só pequenas validações e mensagens p/ tela.

Depois de uma olhadinha:

http://wehavescience.wordpress.com/2012/11/02/um-pouco-sobre-mvc-para-web/

[/quote]

“MVC é um design pattern, no qual visa separar sua aplicação em três camadas, Modelo, Visão e os Controladores.”

Kill me now!

WTF , MVC não é um padrão de separação em camadas!!!

Acho que o pessoal simplesmente perdeu a noção do que são as coisas…
mas que virus memético do inferno :x

Caro kcobainnn remova esse artigo da internet porque é um deserviço à comunidade. Ou altere para que reflita informação correta.
MVC é um padrão que divide um problema em três componentes, não em três camadas.

Nomes de Camadas são Cliente, Apresentação, Dominio , Serviços, Integração. Não aparecem os nomes “modelo”, nem “visão” nem “controlador”.
Serviços não são controladores, e Apresentação não é a “view” e modelo não é o DAO nem as entidades

rs, é exatamente disso que estou falando, pra quem tá começando a internet é o inferno virtual, tem gente falando várias coisas e algumas que até se contradizem(inclusive no próprio guj) agora estou sem tempo mas amanhã vou dar uma estudada nos tópicos do seu(?) blog(alguma outra referência possível?) e ver se entendo a diferença das coisas.

Obrigado a todos de qualquer maneira, vou colocar o tópico como resolvido antes que haja tiroteio, se aparecerem mais dúvidas volto a incomoda-los.

double post

Olá, boa tarde!

Desculpe a demora p/ responder, dei uma pesquisada antes sobre o assunto.
Bem, onde você disse que MVC não tem a ver com camadas até é possível entender, porém o resto não.
Dei uma olhada no seu blog, olhei artigos na internet e etc, porém eu achei muito mais lugares onde exemplificam o MVC da maneira com que expliquei do que com a sua, ou até outras explicações que é diferente de qualquer uma que eu já vi. haha
Okay, eu entendo que você disse que explicações erradas de MVC estão cheias pela internet, porém eu notei que até no seu blog, várias pessoas comentaram a respeito, com a mesma idéia que a minha, além de que, perguntei para alguns amigos e todos tem a mesma idéia que a minha.
Peço desculpas se eu expliquei errado, eu não sou nenhum professor, apenas dei a minha opinião, do que aprendi, do que vejo na maioria das vezes e do que trabalho, mas eu não mudei a minha idéia em relação a isso.
Não estou falando que você está errado, nem que eu estou, nem mesmo os outros que tentaram exemplificar, de qualquer modo, vou continuar lendo a respeito.

[]'s

[quote=kcobainnn]Olá, boa tarde!

Desculpe a demora p/ responder, dei uma pesquisada antes sobre o assunto.
Bem, onde você disse que MVC não tem a ver com camadas até é possível entender, porém o resto não.
Dei uma olhada no seu blog, olhei artigos na internet e etc, porém eu achei muito mais lugares onde exemplificam o MVC da maneira com que expliquei do que com a sua, ou até outras explicações que é diferente de qualquer uma que eu já vi. haha
Okay, eu entendo que você disse que explicações erradas de MVC estão cheias pela internet, porém eu notei que até no seu blog, várias pessoas comentaram a respeito, com a mesma idéia que a minha, além de que, perguntei para alguns amigos e todos tem a mesma idéia que a minha.
Peço desculpas se eu expliquei errado, eu não sou nenhum professor, apenas dei a minha opinião, do que aprendi, do que vejo na maioria das vezes e do que trabalho, mas eu não mudei a minha idéia em relação a isso.
Não estou falando que você está errado, nem que eu estou, nem mesmo os outros que tentaram exemplificar, de qualquer modo, vou continuar lendo a respeito.

[]'s[/quote]

Mas leia de lugares certos. Sinceramente, o Sergio está coberto de razão, não importa se existem N lugares na internet dizendo o contrario. Mesmo porque mal Design é o que mais tem, e é um dos principais fatores que fazem o desenvolvimento de software falhar do modo que falha hoje. Leia os livros do Eric Evans (Criador do DDD), leia o que o Martin Fowler (Se eu preciso dizer quem é…) diz a respeito… Autores extremamente conceituados e que dizem exatamente o que o Sergio está dizendo.

É por toda essa confusão que ter referências é importante. :slight_smile:

Caso contrário, vale a palavra de cada um.

[quote=kcobainnn]Olá, boa tarde!

Desculpe a demora p/ responder, dei uma pesquisada antes sobre o assunto.
Bem, onde você disse que MVC não tem a ver com camadas até é possível entender, porém o resto não.
Dei uma olhada no seu blog, olhei artigos na internet e etc, porém eu achei muito mais lugares onde exemplificam o MVC da maneira com que expliquei do que com a sua, ou até outras explicações que é diferente de qualquer uma que eu já vi. haha
Okay, eu entendo que você disse que explicações erradas de MVC estão cheias pela internet, porém eu notei que até no seu blog, várias pessoas comentaram a respeito, com a mesma idéia que a minha, além de que, perguntei para alguns amigos e todos tem a mesma idéia que a minha.
Peço desculpas se eu expliquei errado, eu não sou nenhum professor, apenas dei a minha opinião, do que aprendi, do que vejo na maioria das vezes e do que trabalho, mas eu não mudei a minha idéia em relação a isso.
Não estou falando que você está errado, nem que eu estou, nem mesmo os outros que tentaram exemplificar, de qualquer modo, vou continuar lendo a respeito.

[]'s[/quote]

Basicamente seu argumento é: Se mais pessoas acreditam em X, X é verdade. Isto é uma falácia argumentativa chamada Argumentum ad Numerum.
O que quero dizer com isto é que não apenas vc não defendeu sua opinião, vc apresentou um argumento que é inválido para começo de conversa.

Infelizmente, por alguma razão desconhecida, muitas pessoas confundem o conceito de MVC com separação em Camadas. E como eu explico no meu blog, isso significaria que todos os sistemas do universo teriam apenas 3 camadas. O que é falso. E vc mesmo no seu blog acrecenta uma camada a mais. Camadas são camadas e vc pode ter tantas quando precisar. MVC é um padrão de componentes e só existem 3 tipos. Estes conceitos não se misturam, mas as pessoas adoram usar os nomes do MVc para as suas camadas. E dizem frases como “Vamos pintar aquele campo de vermelho na view” querendo dizer “vamos pintar o campo de vermelho na camada de apresentação”.

Suas desculpas não são suficientes. É necessário que vc se retrate. Primeiro que entenda o conceito certo, porque vc mesmo está enganado. E depois que pare de divulgar informação errada e divulgue a certa.
Não é uma questão de vc estar certo e eu errado, é uma questão de que existe um conceito correto de MVC e de Separação de Camadas e vc não sabe quais são, nem sabe a diferença. E como vc, muitos.

E além disso ainda ha uma confusão entre separação de camadas e separação de pacotes que confunde ainda mais as cabeças -já confusas - das pessoas.