Camada de Controle

26 respostas
williancontac

É possível ter apenas uma classe de controle que sirva para todas as views do meu sistema? OU eu tenho que criar um controle para cada um?
Exemplo:

tenho uma classe chamada Controle.class e gostaria que servi-se para todas ao invés de criar ControlCliente.class, ControlProdutos.class e etc…

alguém poderia me dar uma luz…

segue meu código abaixo:

package control;

import java.util.List;

import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;

public class Controle {
	private SessionFactory sf;
	private Session session;
	private Transaction tx;

	@SuppressWarnings("deprecation")
	public Controle() {
		sf = new Configuration().configure().buildSessionFactory();
		session = sf.openSession();
		tx = session.getTransaction();
	}

	public List<?> getLista(Object object) {
		tx.begin();
		List<?> lista = session.createCriteria(object.getClass()).list();
		session.flush();
		tx.commit();
		return lista;
	}

	public void remover(Object object) {
		tx.begin();
		session.delete(object);
		session.flush();
		tx.commit();
	}

	public void salvar(Object object) {
		tx.begin();
		session.saveOrUpdate(object);
		session.flush();
		tx.commit();
	}
}
package test;

import java.util.List;

import model.Contato;
import control.Controle;

public class ListarContatos {
	@SuppressWarnings("unchecked")
	public static void main(String[] args) {
		Contato object = (Contato)new Object();
		Controle controle = new Controle();
		List<Contato> listaContatos = (List<Contato>) controle.getLista(object);
		for(Contato c : listaContatos){
			System.out.println("Nome:" + c.getNome());
		}
	}
}

26 Respostas

jeffev

Você pode criar uma classe controle que seja genérica que tratara do comportamento normal das classes, e para as operações especificas de cada classe você faz uma classe que estende essa genérica e implementa os métodos específicos para ela.

Ruttmann

Cara, acho que no seu caso não vais conseguir fazer isso com apenas um controller…

Vi pelo seu exemplo que você tem que lidar com clientes, produtos e etc. Certamente esses objetos não vão ter os mesmos comportamentos, ou talvez até tenham, mas com a adição de outros comportamentos específicos.

Portanto, fica a dica abaixo:

jeffev:
Você pode criar uma classe controle que seja genérica que tratara do comportamento normal das classes, e para as operações especificas de
cada classe você faz uma classe que estende essa genérica e implementa os métodos específicos para ela.

Recomendo essa prática também…

:wink:

williancontac

Neste caso eu posso usar o Polimorfismo e Herança?
Pelo cenário eu crio uma classe Mãe e a utilizo herdando nas filhas e depois se eu precisar de algum outro método eu implemento na classe filha utilizando a teoria do Polimorfismo.
No meu caso, eu estou ate conseguindo, gravar, remover, e editar dessa maneira com o código acima, mas o problema só está acontecendo na hora de trazer a lista de dados.
Então eu crio uma classe geral para implementar o CRUD e depois eu implemento nas classes secundárias apenas os métodos de listagem.
Veja se o meu raciocínio estar correto?

Obrigado!

rmendes08

Amigo, o que você está tentando fazer é um DAO, e isso não tem nada a ver com camada de controle.

Pelo o que eu entendi, o que você quer é um DAO genérico. Se o que você quer é um DAO apenas com os métodos para o CRUD, é perfeitamente possível fazer 1 único DAO para toda a sua aplicação.

williancontac

rmendes08:
Amigo, o que você está tentando fazer é um DAO, e isso não tem nada a ver com camada de controle.

Pelo o que eu entendi, o que você quer é um DAO genérico. Se o que você quer é um DAO apenas com os métodos para o CRUD, é perfeitamente possível fazer 1 único DAO para toda a sua aplicação.


Desculpe, minha ignorancia, mas não estou querendo um DAO, eu quero que todas as outras classes VIEWS implementem um Controle só. DAO é um paradigma Procedural e não OOP. Se é que me entendeu!

Ruttmann

williancontac:
rmendes08:
Amigo, o que você está tentando fazer é um DAO, e isso não tem nada a ver com camada de controle.

Pelo o que eu entendi, o que você quer é um DAO genérico. Se o que você quer é um DAO apenas com os métodos para o CRUD, é perfeitamente possível fazer 1 único DAO para toda a sua aplicação.


Desculpe, minha ignorancia, mas não estou querendo um DAO, eu quero que todas as outras classes VIEWS implementem um Controle só. DAO é um paradigma Procedural e não OOP. Se é que me entendeu!

Entendi, mas essa classe que você postou é um DAO, ela não provê controle de fluxo pra sua aplicação, apenas cuida das transações com Banco de Dados.

Uma classe de controle contêm todas as lógicas de negócio da sua aplicação, é onde realmente está contida a lógica propriamente dita do seu programa.

Outra característica interessante da classe de controle é sua ligação com a view. Leia-se ligação não como acoplamento, mas sim como relação, pois a camada de controle manipula a informação que lhe é repassada da camada view, e a partir disso faz uso da DAO para rotinas inerentes ao Banco de Dados.

Enfim, voltando à sua dúvida, no caso dessa DAO é possível fazer apenas uma para todos os seus objetos, bem como o rmendes08 falou acima.

:wink:

rmendes08

williancontac:
rmendes08:
Amigo, o que você está tentando fazer é um DAO, e isso não tem nada a ver com camada de controle.

Pelo o que eu entendi, o que você quer é um DAO genérico. Se o que você quer é um DAO apenas com os métodos para o CRUD, é perfeitamente possível fazer 1 único DAO para toda a sua aplicação.


Desculpe, minha ignorancia, mas não estou querendo um DAO, eu quero que todas as outras classes VIEWS implementem um Controle só. DAO é um paradigma Procedural e não OOP. Se é que me entendeu!

DAO == paradigma procedural ? Desde quando ? O Object no final não te diz nada ? http://corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm

De qualquer maneira, é você que está trocando as bolas. O código que você postou é um DAO. Não é porque o nome da classe é Controle que ela é um controller, mas o que você está fazendo nesse código é abstrair o acesso aos dados, e abstrair acesso aos dados é responsabilidade do DAO.

rmendes08

Isso também está errado. Controller não contém regras de negócio, eles servem simplesmente para delegar requisições da View para o Model, e entregar objetos do Model para a View. A lógica de negócios também é parte do Model.

Ruttmann

rmendes08:

Uma classe de controle contêm todas as lógicas de negócio da sua aplicação, é onde realmente está contida a lógica propriamente dita do seu programa

Isso também está errado. Controller não contém regras de negócio, eles servem simplesmente para delegar requisições da View para o Model, e entregar objetos do Model para a View. A lógica de negócios também é parte do Model.

Cara, agora não entendi mais nada. Até onde aprendi MVC sempre foi assim como falei que me explicaram. Você tem um exemplo fácil pra me ilustrar a sua explicação?

:roll:

rmendes08

Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

williancontac

Ruttmann:
rmendes08:

Uma classe de controle contêm todas as lógicas de negócio da sua aplicação, é onde realmente está contida a lógica propriamente dita do seu programa

Isso também está errado. Controller não contém regras de negócio, eles servem simplesmente para delegar requisições da View para o Model, e entregar objetos do Model para a View. A lógica de negócios também é parte do Model.

Cara, agora não entendi mais nada. Até onde aprendi MVC sempre foi assim como falei que me explicaram. Você tem um exemplo fácil pra me ilustrar a sua explicação?

:roll:

Nem eu estou entendendo mais nada. :smiley:
Mais a DAO não poderia ser uma camada de Controle, já que fazemos referencia ao modelo e repassando para a View?

williancontac

rmendes08:
Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

No meu caso eu estou desenvolvendo para Desktop. Que eu saiba Desktop precisa de Servlets?

wagnerfrancisco

williancontac:
rmendes08:
Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

No meu caso eu estou desenvolvendo para Desktop. Que eu saiba Desktop precisa de Servlets?

No caso de aplicações desktop você deve pensar nas ações do usuário. Pode haver um controller que mapeia as ações para o teu modelo.

Controller não é camada, é um componente do padrão MVC. MVC e DAO são coisas completamente distintas.

Se tu vai acessar os DAOs direto da tua View, possivelmente tua View vai conter a lógica da aplicação, o que não é recomendável.

williancontac

Então, pelo que eu entendi o DAO é apenas a camada de persistencia do ORM? É isso? Então, eu aproveito para perguntar, tem como eu produzir um DAO que sirva para todos?

rmendes08

williancontac:
rmendes08:
Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

No meu caso eu estou desenvolvendo para Desktop. Que eu saiba Desktop precisa de Servlets?

Não precisa, eu apenas citei um exemplo no contexto das aplicações Web.

No caso das aplicações desktop, um Controller não tem nada de especial em termos de especificação, basta ela cumprir com o seu papel de delegar eventos do usuário para classes que implementam regras de negócio.

rmendes08

Sim, desde que as operações do seu DAO genérico se aplique a todas as entidades do seu sistema.

wagnerfrancisco

DAO não é a camada. Ele faz parte da camada de persistência. DAO abstrai os dados que podem estar num banco, num arquivo xml ou onde for. Usando ORM a nomenclatura DAO fica até um pouco estranha, mas continua sendo utilizada.

Como o rmendes08 comentou você pode ter um DAO genérico. Se o teu DAO for simples como postou inicialmente, você pode criar um GenericDAO que utiliza Generics para identificar os tipos das entidades. O problema é quando tiver métodos específicos (como o Ruttmann comentou). Aí você herda do DAO genérico e adiciona os métodos que desejar.

No site do próprio hibernate há um exemplo de DAO genérico que funciona com o hibernate:

https://community.jboss.org/wiki/GenericDataAccessObjects

Veja o GenericHibernateDAO.

Ruttmann

rmendes08:
Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

Pior é ver que 70% dos desenvolvedores tem essa concepção de MVC igual a mim.

Obrigado pelo links rmendes08 vou estudar mais sobre isso. E lendo esses conceitos corretos de MVC notei vários problemas em códigos que estou trabalhando no momento, que seguem a mesma lógica que eu achava ser certa.

Só espero que esse conceito de MVC não mude de novo. :roll:

Várias coisas que achei que fossem certas já foram derrubadas por outras teorias, mas continuo estudando!

:smiley:

JavaThai

williancontac:
rmendes08:
Pois é, mas tem muita gente que lê meia dúzia de apostilas na Internet e acha que é professor de Eng. de Software, mas enfim, tem muita coisa errada sobre MVC na Internet, esse post ajuda a esclarecer um pouco:

Enfim, não tenho nenhum código pronto para postar, mas você poderia pensar assim:

View: interfaces, JSP’s, HTML, CSS, Javascript, etc.
Controller: Servlets ou ManagedBeans, recebem requisições da View e delegam para o Model
Model: domínio e regras de negócio, basicamente ficam o serviços e entidades do sistema

No meu caso eu estou desenvolvendo para Desktop. Que eu saiba Desktop precisa de Servlets?

Bom Dia williancontac!
Mano o recomendado e vc usar praticas legiveis com vão te ajudar hoje e amanhã com o codigo!
O no meu ponto de vista vc tem q criar um dao para cada objeto que vc for manipular no banco ,seguindo os paradigmas OO e almentando a legibilidade do seu código!
O dao é utilizado para acessar e manipular os dados do banco!
Cara vc só falor que estava desenvolvendo para desktop no seu penultimo post,da próxima vez coloque no começo assim evitar a perca de tempo!

Cara esse link teve te ajudar mais com o desenvolvimento para desktop!

williancontac

Resolvido. Mas uma vez fico com mais dúvidas do que respostas. Mas valeu, gente! Obrigados a todos!

RafaelCassau

A classe de exemplo que foi postada se refere a persistencia de dados, seja ela em banco, XML, TXT ou qualquer outro jeito, para persistencia de dados existe um padrão chamado DAO - Data Acess Object que encapsula toda a parte de perssistencia, o DAO fica dentro da camada MODEL, mas esse não é o seu problema, o que você quer saber é se com uma unica classe Controller você seria capaz gerenciar suas Views, dessa maneira sua Controller não ira ficar modularizada, pense assim, seu sistema tem 5 Views dentro de uma unica Controller, amanha depois seu sistem passa a ter 20 Views para uma unica Controller, almentaria muito a complexidade e a manutenibilidade, alem de tudo sua Controller não ficaria Coesa e bastante acoplada o que diminui e muito a qualidade do projeto, a coesão prega que você deve ter muitas classes com 1 unica responsabilidade cada, ou seja, crie um Controller para cada View, e referente ao DAO você pode ter um DAO generico pois todas as operações do mesmo são resumidas em CRUD que são comuns a todos os clientes do DAO, ae quando for ter consulta é so especializar ele através de herança para cada entidade especifica.

espero ter ajudado.

williancontac

RafaelCassau:
A classe de exemplo que foi postada se refere a persistencia de dados, seja ela em banco, XML, TXT ou qualquer outro jeito, para persistencia de dados existe um padrão chamado DAO - Data Acess Object que encapsula toda a parte de perssistencia, o DAO fica dentro da camada MODEL, mas esse não é o seu problema, o que você quer saber é se com uma unica classe Controller você seria capaz gerenciar suas Views, dessa maneira sua Controller não ira ficar modularizada, pense assim, seu sistema tem 5 Views dentro de uma unica Controller, amanha depois seu sistem passa a ter 20 Views para uma unica Controller, almentaria muito a complexidade e a manutenibilidade, alem de tudo sua Controller não ficaria Coesa e bastante acoplada o que diminui e muito a qualidade do projeto, a coesão prega que você deve ter muitas classes com 1 unica responsabilidade cada, ou seja, crie um Controller para cada View, e referente ao DAO você pode ter um DAO generico pois todas as operações do mesmo são resumidas em CRUD que são comuns a todos os clientes do DAO, ae quando for ter consulta é so especializar ele através de herança para cada entidade especifica.

espero ter ajudado.

Rapaz, perfeito sua explicação. Clareou minhas ideias agora, neste caso eu não estou utilizando totalmente o padrão MVC e sim um misto de Persistência com Model e View. Seria isso?

williancontac

Continuo concordando com Python. Obrigados a todos!

rmendes08

RafaelCassau:
A classe de exemplo que foi postada se refere a persistencia de dados, seja ela em banco, XML, TXT ou qualquer outro jeito, para persistencia de dados existe um padrão chamado DAO - Data Acess Object que encapsula toda a parte de perssistencia, o DAO fica dentro da camada MODEL, mas esse não é o seu problema, o que você quer saber é se com uma unica classe Controller você seria capaz gerenciar suas Views, dessa maneira sua Controller não ira ficar modularizada, pense assim, seu sistema tem 5 Views dentro de uma unica Controller, amanha depois seu sistem passa a ter 20 Views para uma unica Controller, almentaria muito a complexidade e a manutenibilidade, alem de tudo sua Controller não ficaria Coesa e bastante acoplada o que diminui e muito a qualidade do projeto, a coesão prega que você deve ter muitas classes com 1 unica responsabilidade cada, ou seja, crie um Controller para cada View, e referente ao DAO você pode ter um DAO generico pois todas as operações do mesmo são resumidas em CRUD que são comuns a todos os clientes do DAO, ae quando for ter consulta é so especializar ele através de herança para cada entidade especifica.

espero ter ajudado.

Veja bem, não há tanto problema assim em se manter um único controlador para todas as views. Por exemplo, aqui onde trabalho é assim. As interfaces do nosso sitema são feitas em Flex, e no lado servidor usamos Servlets e EJB’s. Quando precisamos acessar algum serviço, a view encaminha para o controller uma requisição com o nome do serviço e seus argumentos em XML. O Controller por sua vez, tem um mapeamento entre o nome do serviço e o EJB que oferece o serviço. Por fim, o método é invocado através de reflection.

Enfim, no final das contas, tudo depende das operações executadas pela interface. Geralmente CRUD’s tem poucas regras de negócio, e o que muda são as entidades do cadastro. Nesses casos, pode valer a pena fazer um único Controller para todas a Views.

RafaelCassau

williancontac no seu caso você está dizendo que sua controller faz a parte de persistencia de dados, sendo assim você trocou as bolas na verdade essa seria uma DAO a Controller iria apenas delegar requisições para a Model que contem suas entidades e seus negocios que podem ficar em classes separadas ou nas proprias entidades mesmo, agora a classe que você criou para listar contatos não seria uma classe e sim um método da DAO referente aos a persistencia da entidade Contato, espero ter ajudado.

rmendes08, intendi o que você quiz dizer, no contexto do sistema no qual você trabalha funciona bem sim, porem isso depende muito do contexto do sistema, onde trabalho desenvolvemos sistemas para o governo com lógica pesada, então no nosso caso ficaria inviavel tal abordagem.

rmendes08

RafaelCassau:
williancontac no seu caso você está dizendo que sua controller faz a parte de persistencia de dados, sendo assim você trocou as bolas na verdade essa seria uma DAO a Controller iria apenas delegar requisições para a Model que contem suas entidades e seus negocios que podem ficar em classes separadas ou nas proprias entidades mesmo, agora a classe que você criou para listar contatos não seria uma classe e sim um método da DAO referente aos a persistencia da entidade Contato, espero ter ajudado.

rmendes08, intendi o que você quiz dizer, no contexto do sistema no qual você trabalha funciona bem sim, porem isso depende muito do contexto do sistema, onde trabalho desenvolvemos sistemas para o governo com lógica pesada, então no nosso caso ficaria inviavel tal abordagem.

Mas nosso sistema também possui muitas regras de negócio. No meu caso, trabalho em um produto que deve atender a centenas de clientes diferentes (e não estou falando de usuários aqui, centenas de empresas mesmo). Assim regra de negócio é o que não falta … Porém isso é possível porque:

  • o controller foi pensado de forma que ele seja desacoplado da view
  • todos os serviços do sistema seguem uma assinatura comum: todos os métodos que implementam serviços recebem um único argumento, que representa o contexto do serviço, a única incoveniência é que o serviço tem que navegar pelo XML enviado pelo client, mas isso poderia ter sido automatizado

Aqui, ninguém mais faz CRUDs simples, isso porque é uma tarefa completamente automatizada, basta criar as tabelas no banco de dados e inserir as informações nas tabelas de metadados que o sistema cuida de renderizar o CRUD.

Existem sim outros controllers, mas eles são específicos para impressão ou download de documentos.

Criado 30 de setembro de 2012
Ultima resposta 2 de out. de 2012
Respostas 26
Participantes 7