DAO - Design Patterns

13 de maio de 2007 3 respostas

Alexandre_Ferreira1 13 de maio de 2007

Pessoal,
Gostaria de saber se ainda é uma boa pratica fazer o Design Patterns abaixo usando o Ibatis com framework de persistência.
Visto que as query ficam no XML, por isso surgiu a duvida de continuar "programando" com 2 interface e 2 classes no mínimo para cada entidade:
Antigamente a gente precisava porque o gerenciador das Query eram a nossas classes, mas hoje em dia usando o Ibatis ou Hibernate, me deixa
inseguro quanto ao uso dessas quantidades de DAOs e SERVICEs. Acredito que com apenas 1 interface e 1 classe seja suficiente...

DAOs

package br.com.afs.persistence;
import br.com.afs.business.Cliente;

public interface ClienteDAO {
     public Integer doInsert(Cliente cliente);
 }

package br.com.afs.persistence;
 import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
 import br.com.afs.business.Cliente;

 public class ClienteIbatisDAO extends SqlMapClientDaoSupport implements ClienteDAO {

     public Integer doInsert(Cliente cliente) {
         return (Integer)super.getSqlMapClientTemplate().insert("doInsert", cliente);
     }
 }

SERVICEs

package br.com.afs.service;
 import br.com.afs.business.Cliente;

 public interface ClienteService {
     public void doInsert(Cliente cliente);
 }

package br.com.afs.service;
 import br.com.afs.business.Cliente;
 import br.com.afs.persistence.ClienteDAO;

 public class ClienteDAOService implements ClienteService {
     private ClienteDAO dao;

     public void setDao(ClienteDAO dao) {
         this.dao = dao;
     }
     public void doInsert(Cliente cliente) {
         dao.doInsert(cliente);
     }
 }

3 Respostas

vcjava 13 de mai. de 2007

Especifique o Pattern que esta usando grato.

tiagogn 13 de mai. de 2007

Acho interessante vc fazer com q as classes q implementem as interfaces de DAO, façam acessos “burros” ao banco de dados, com apenas os sql’s, já nas classes Service(Business) ficam sua logica de negocio q precisam operar sobre os dados retornados do BD, e usando o conceito de IoC vc acaba desacoplando tua regra de negocio a qq classe de acesso a dados, com isso facilitando até mesmos os testes unitários de tuas regras de negocio…bom essa é minha opnião !

Ate+

Alexandre_Ferreira1 13 de mai. de 2007

Ainda não muito satisfeito acabei fazendo o seguinte: Generic DAO

public interface GenericDAO<Classe, PK> {

	/**
	 * @param <Classe>
	 * @return PK save
	 */
	public PK doInsert(Classe classe);
}

Cliente DAO * se precisar implementar algo diferente do GenericDAO.

public interface ClienteDAO extends GenericDAO<Cliente, Integer> {
	/**
	 * @return List<Cliente> findByName
	 */
	public List<Cliente> doSelectName(String name);
}

Vamos supor que eu precisei implementar o doSelectName que só existe para o Cliente.

ClienteDAOImpl

public class ClienteDAOImpl extends SqlMapClientDaoSupport implements
		ClienteDAO {

	public List<Cliente> doSelectName(String name) {
		// TODO Auto-generated method stub
		return null;
	}
	public Integer doInsert(Cliente classe) {
		// TODO Auto-generated method stub
		return null;
	}
}

Criado 13 de maio de 2007

Ultima resposta 13 de mai. de 2007

Respostas 3

Participantes 3

3 Respostas

Topicos relacionados